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제 1 장. 개 팔 


UNIX (유닉 스)에 대 하여 오래동안 연구도 해 왔고 일정한 기 간 Linux (리눅스)를 사용 
해 온 연구자들까지도 일반적으로 Linux 에서 자료를 어떻게 기억시키며 어떻게 검색하는 
가에 대해서는 잘 알고 있다고 생각해 왔다. 

그런데 지 난 2000년 가을에 있은 UNIX 토론회 에서는 정규 Linux 파일체계 * 1 로부터 일 단 
잃어 졌다고 생각되는 파일을 아주 쉽게 다시 회복시켰다는 내용이 제기되여 열린 파일 
이 지워 지면 그 파일을 다시 회복시 킬수 없다고 한 주장이 사라지게 되였다. 

이 로부터 Linux 에서 체 계의 믿음성과 안정성보호문제 가 중요하게 제 기되 였다. 

GNU / Unux 와 파일체계 

최 초에 Linux 는 Minix (미 닉 스)* 2 조작체 계 하에 서 교차개 발되 였 다. 리 누스 토발즈 (Linus 
Torvalds) 는 처음부터 새로운 파일체계를 설계하는것보다는 두개의 체계사이 에서 디스크를 공 
유할수 있다는데로부터 이러한 방법을 선택하였다. 

Minix 파일 체 계 는 아주 효과적 이였 으며 상대 적 으로 오유에 안정한 쏘프트웨어 였 다. 
그러 나 Minix 파일체계는 제 한조건이 너무 강하였기때 문에 사람들은 점 차 Linux 에서 새로 
운 파일 체 계 를 실 현하기 위한 연구를 시 작하게 되 였 다. 

Linux 핵 심 부 (Linux kernel) 에 새 로운 파일 체 계 를 보다 쉽 게 첨 가하기 위 하여 가상파일 
체 계 층 (Virtual File System Layer) 이 개 발 (Chris Provenzano 에 의 하여 )되 였 는데 이 가상파일 
체계층은 후에 Linux 핵심부로 종합완성되기에 앞서 리누스 토발즈에 의하여 다시 서술되 
였다(이 내용에 대 해서는 이 책의 가상파일체 계 에서 설명한다.). 가상파일체계 가 Linux 의 
핵 심부로 완성된후 확장파일체 계 (extended File System (ext)) 라고 부르는 새 로운 파일체 계 
가 1992년 4월에 실현되 였으며 Linux 판본 0.96 으로 보충되 였다. 

이 새 로운 파일 체 계 는 Minix 의 두가지 큰 제 한성 을 극복하였 는데 하나는 최 대파일 크기 
가 2GB 인것 이 고 다른 하나는 최 대파일 이 름길 이 가 255문자인것이 였 다. 

ext 파일체계는 Minix 파일체계에 비해서는 훨씬 개선되였으나 여전히 자체의 부족점 
을 가지고 있었다. 

그러한 부족점들로는 접근분리，색인마디변경，자료변경시간표식 5153 등을 지원하지 못 
하는것을 들수 있다. 


Linux ext2 파일체계에서 어떤 파일을 지울 때 등록부입구점은 지워 지지 않는다. 결과 적어도 
등록부입구점이 재쓰기되기전까지는 이름대색인마디넘기기가 보존된다. 그러므로 사용자는 ■층* i. 
록부행 블로크들에 접 근하여 지 워 진 파일 의 이 름과 색 인마디번 호를 찾을수 있 으며 따라서 첫 
12개 혹은 직접 블로크에 접근할수 있다. 

Minix 와 그 파일체계는 교육목적 으로 개 발되 였다 (Andrew Taneu baum 에 의 하여). 

이 특성 은 다음장들에 서 설 명한다. 




ext 파일 체 계 는 그 파일 체 계안의 자유블로크와 색 인마디 들을 쉽 게 추적 하기 위하여 
핵심부안에서 련결목록을 리용하였으나 역시 새로운 불합리성에 직면하였다. 즉 파일체 
계리용은 개선되였으나 련결목록이 정렬되지 않고 파일체계가 토막으로 분리되는것 으로 
하여 불합리한 파일 체 계 의 겹 침 현상이 초래 되 게 되 였 다. 

이러한 문제점들에 대응하여 두개의 새로운 파일체계가 1993 년초에 발표되였는데 하 
나는 Xia 파일 체 계 (Xiafs) 이 고 다른 하나는 2 차확장파일 체 계 (Second Extended File System) 
즉 ex 松 fs 였다. 

Xia 파일체계는 기본적으로 Minix 파일체계에 기초하였으며 다만 몇가지 기본개선대책 
만을 보충하였다. 

이 파일체계는 Minix 처 럼 긴 파일 이름을 제공하며 보다 큰 구획 (Partition) 도 지 원하 
며 세 가지 시 간표식기 능 즉 시 간생 성，시 간변경，시 간접근기능을 지원 한다. 

한편 ext2fs 는 확장파일체계코드에 기초하였으며 상당히 개선되 였다. 

이 파일체계는 그 시작으로부터 보다 개선된 성능확장에 목적을 두고 설계되였다. 
두개의 새로운 파일체계 가 처음으로 발표되 였을 때 그것들은 서 로 다른 실현방식과 원천 
코드를 가지고 있지만 본질적 으로는 같은 특성을 제공하였다. 

또한 설계 의 최 소화에 의하여 Xiafs 는 실제 적 으로 ext2fs 보다 더 안정하였 다. 결국 
ext2fs 에서는 오유가 고정되고 많이 개선되여 새로운 특성들이 보충되였다. 

오늘 ext2fs 는 대단히 안정하며 사실에 있어서 표준 Iinux 파일체계로 되였다. 

이 책은 ext2fs 의 넓은 범위와 함께 현재 Linux 에서 리용가능한 모든 중요한 파일체 
계들에 대하여 고찰하며 그것들의 우점과 결점을 시험하고 어떻게 효과적으로 리용하겠 
는가를 고찰한다. 

이 책의 목적 

이 책은 현재 Linux 용으로 리용할수 있는 가장 중요한 파일체계들에 대한 일반적리 
해를 더 깊이 할 목적으로 서술되였다. 

파일체 계를 완전히 리해하려면 그 파일체계 가 어떻게 서술되 였는가를 때때 로 알아 보 
아야 한다. 

그러 나 이 파일체계들의 원천코드를 해설하는것 이 아니 라 언제 어느 파일체계를 효 
과적 으로 사용하겠는가를 보여 주는것 이 이 책의 목적 이 다. 아래 에 광범히 쓰이는 몇개 
의 용어 들을 소개한다. 

▼ 핵 심 부 (kernel) 는 보호방식 에서 실행 되 며 장치 의 특권준위등록기 들에 접 근할수 있 
는 조작체 계 프로그람이 다. 

• 파일체계는 사용자나 체계자원의 서로 독립적 인 저장통을 표현하는 조종블로크 
들의 론리적집합이다. 《파일체계》라는 용어를 쓸 때는 일정한 애매성이 존재 
한다. 용어 를 리용하는 한가지 측면은 ex 任 fs 나 NFS 와 같은 특정한 파일 체 계 의 
종류에 대하여 고찰할 때이며 다른 한 측면은 /usr 나 혹은 /boot 와 같은 파일체계 
의 특정 한 실 례 를 고찰할 때 이 다. 
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• 이 름공간 (name space) 은 파일 이 름과 같이 일 의 적 으로 지 정 된 식 별 자들의 모임 이 
다. 이름공간안에서 파일이름은 한가지 실례에 불과하다. 일반적으로 이름공간은 
등록부범 위안에 포함된 다. 

▲ 등록부 (directory) 는 파일 체 계 에 의 하여 유지 관리 되 는 특별 한 파일 이 다. 등록부에 
는 입구점 (entry) 들의 목록이 포함된다. 사용자에게 있어서 어떤 입구점은 파일이름 
으로 표현되며 그것은 기 호로 표현된 입구점이름에 의 하여 접근되는데 이때의 기 호 
입 구점 이 틈은 사용자의 파일 이 름으로 된 다. 

이 책들 읽어야 할 사람 

이 책 은 체 계관리 자，망관리 자，개 발자의 능력 을 높여 주자는데 그 목적 이 있다. 그 
러므로 이 책은 또한 장치와 프로그람에 대한 일반적인 리해를 더 잘 가지려고 하는 
Linux 애 호가들에 게 도 호감을 가지 게 한다. 다음장들에 서 체 계관리 자들은 특정한 파일 체 
계에 핵심부를 어떻게 준비하며 어느 체계를 리용할수 있으며 그것들을 어떻게 정확하게 
사용하겠는가를 배우게 된다. 또한 자연스러운 환경에서 파일체계를 전환하여 상당한 정 
도로 체계성능을 높여 나갈수 있게 될것이다. 개발자들은 자기들의 응용실천에 파일체계 
가 어떻게 영향을 주는가를 알게 된다. 많은 사람들이 개발자들에게는 파일체계가 실지 
로 명백하다고 말하고 있지만 사실은 그렇지 않다. 실례로 잠금기술이 파일체계에 의하 
여 효과적 으로 실현된다는것 을 안다는것 은 프로그람작성 자나 체계개 발자들로 하여금 이 
기능성을 응용한 코드를 만들지 않아도 되게 한다. 

이 책들 읽기전에 알아야 할 내용 

콤퓨터 과학리 론의 일 반적개 념 특히 이 름공간구역 이 나 입 출력개 념 을 잘 가지 는것 은 
아주 중요하다. 

또한 독자가 Linux 대 면부의 동작지식 과 기 본체 계관리 에 무엇 이 포함되 는가에 대 한 
기초적 인 리해를 가지 고 있다면 더욱 좋다. 

파일 체 계 에 대 한 예 비 지 식 은 없 어 도 된 다. 제 공되 고 있는 대 다수의 코드들을 알고 
있 다고 해 도 C 언어프로그람을 읽 을수 있는 편 이 더 좋다. 

C 언어 에 대 하여서는 C 언어의 설계 자들인 Kernighan/Ritche 가 쓴 C Programming 
Language 를 소개 할수 있 다. 

이 책의 내용 

이 책은 Linux 조작체 계 에 대 한 간단한 요약과 함께 그것을 조작하는 방법 을 내용으 
로 하고 있다. 또한 책은 Linux 핵심부의 재를파일을 어떻게 진행하는가에 대하여 서술하 
고 있는바 이 것은 표준 Linux 배 포판핵 심 부로 선행 를파일되 지 않은 파일체 계 의 리용에서 
중요한 지 식 으로 된다. 일 반 UNIX 의 파일 체 계 에 대 하여 고찰해 보면 가상파일체 계 
(Virtual File system : VFS) 를 통하여 Linux 의 파일체 계 가상화를 알게 되 며 따라서 모든 
중요한 파일 체 계 들을 고찰하고 설 명할수 있 다. 
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이 책에서는 리용가능한 모든 Linux 파일체계에 대하여 일일이 설명하지 않고 가장 
중요한것들과 그것들을 어떻게 효과적으로 리용하겠는가에 대해서만 관심을 돌려 취급한다. 

이 책의 리용방법 

이 책은 글줄을 따라서 처음부터 마지막까지 읽는것 이 제 일 좋다. 처음에 한번 읽 어 
본후에 는 매 일매 일 파일 체 계 를 리 용하면서 속성 참고서 로 리 용해 도 좋다. 

보다 자세한 내용알아보기 

Linux 파일 체 계 에 대 한 가장 최 신자료는 인 터네 트상에 서 찾아 볼수 있지 만 그것 은 
사실상 행 으로 된 자료에 불과하며 이 자료를 수집하여 그것 을 조립 하고 론리 정 연한 형 
식 으로 정 리 한다는것 은 쉬 운 일 이 아니 다. Linux 파일체 계 의 가장 큰 가치 는 Web 싸이트, 
원천 코드， 론문 등을 통하여 공개 적 으로 리용가능한 자료로 론리 정 연하게 잘 연구되 였으 
며 형 식화된 원 천들을 제 공한다는데 있 다. 

핵심부상에서 홀륭한 정보원천의 하나는 물론 파일체계를 실현하는 핵심부원천코드 
이다. 

이 책에서 언급한 모든 파일체계에 대한 개발자의 우편목록에 대한 서명은 파일체계 
에 관계되는 모든 측면을 알아 내는데서 아주 중요한 방법의 하나이다. 

의견과 해설 

임의의 의견이나 해설에 대해서는 언제나 접수하며 moshe_bar@hotmail.com 이라든지 
혹은 Moshe Bar do McGraw-Hill, professional Book Group, Two Perm Plaza, New York, 
NY 10121 주소를 리용할수 있 다. 

공개원천-현대조작체계의 밀접한 련관 

Linux 가 성 공하게 된것 은 일 반공개 허 가증 (General Public License : GPL) 때 문이 다. 하 
지만 공개원천이나 열린쏘프트웨어의 개념은 흔히 말하고 있는것처럼 실제적으로는 낡았 
다. 공개쏘프트웨 어 의 첫 제 안자는 무료쏘프트웨 어 재 단 (Free Software Foundation : FSF) 의 
리차드 스롤만이였다. 

그는 자기 가 작성 한 몇 가지 우수하고 현재 널 리 보급된 쏘프트웨어 에서 Emacs 편집 환경 
과 c 언어나 C ++ 언어용 gcc 를파일러를 위한 GPL 을 제 안하였다. GNU 수단의 충분한 목록에 대 
해서는 www. gnu. org 를 보라. 리차드 스롤만은 또한 GNU Hard 라고 부르는 대상과제인 완 
전 GNU 조작체 계 에 대 한 연구를 오래 동안 진행하여 왔다. 10 년가까이 개 발해 왔으나 이 OS 
는 여전히 현실성이 없었다. 그후 수많은 유능한 기술자들이 이 대상과제에 힘을 집중하였 
고 그 과정 에 이 대상과제는 Linux, B 狂)와 기 타 다른 OS 에 대 한 개 발방법 을 찾아 내게 되 
였다. 이 조작체계들은 믿음성과 성능이 높은 공개원천으로 된다는데 리로운 점 이 많다. 

Linux 의 믿 음성문제 는 크게 보면 코드를 해 석 하고 그것 을 개 선 하며 또 그것 을 변화 




시키 면서 실 행 시 켜 보는 수백，수천의 개 발자들의 정 교한 조사로부터 시 작되 였 다. Eric 
Raymond 가 자기의 론문 “Cathedral and the Bazar ” 에서 서술한바와 같이 《충분히 큰 
베타테스터와 공동개발자기지가 주어 지면 거의 모든 문제는 빨리 해석되며 누구에게나 
명 백 한것》으로 될 것 이 다. 

따라서 Linux 기초코드를 조사하는 과정에 수많은 의문들이 제기된것으로 하여 어떤 
닫겨 진 모형 의 쏘프트웨 어개 발조직 이 제 공하는것 보다 더 좋은 질 담보 ( QA ) 를 엄 을수 있 
게 한다. 이것은 당연히 더 질 좋은 프로그람을 만들어 내게 한다. 

열린공개원천과 같은 단순한 개 발모형 은 그자체 로 적 당한 설계 와 코드화방법 으로 바 
물수 없지만 길이가 길어 지기때문에 배정된 길이를 초과한다. 

Unux 으 I 력사 

성공한 수많은 력사와 마찬가지로 Linux 도 필요성으로부터 제기된 대상과제의 하나 
토서 시작되였다. 

1991년에 핀란드의 헬싱키종합대학의 대학생이였던 리누스 토발즈는 소편상에서 
가상기억관리를 지원하는 첫 인텔 CPU 인 D 86 에 기초한 PC 를 자체로 준비하였다 
(1991 년). 

MS - DOS 조작체계 에 완전하게 만족을 느끼지 못한 그는 MS - DOS 대 신 자기의 PC 에 
Minix 조작체 계 를 실 현 할것 을 결 심하였 다. 

그는 곧 자기 가 연구하는데 필 요한 함수들과 특성 들을 준비 하기 위하여 Minix 에 힘 
을 넣 었다. 그후 그는 Minix 가 학술연구용 OS 로서 는 너 무 컸으므로 처 음부터 조작체 계 를 
만들것 을 결 심하였 다. 

토발즈는 또한 중요하게 Linus 와 Unix 를 합하여 Linux 라는 이름으로 자기의 새로운 
조작체계의 원천코드를 인터네트상에서 자유롭게 리용할수 있게 즉 공개원천으로 리용할 
수 있게 만들것 을 결심하였 다. 

첫 판본 0.()1 은 1991년 8월 에 인 터네 트로부터 자료를 받을수 있게 만들어 졌 다. 같은 
해 10월 에 리누스는 판본 0.02 의 유용성 을 공식 적 으로 발표하였 다. 이 판본은 이 미 bash 
shell , GNU gcc 를파일 러 그리 고 다른 기 본적 인 편의 프로그람과 같이 UNIX 사용자구역 
( Unix - user - land ) 프로그람을 실 행 할수 있 었 으며 또한 그리 많지 않았지 만 다른 기 본적 인 
유용성도 실현할수 있었다. 

이 대 상과제 의 공개원 천 성 에 의하여 즉시 에 리용할수 있 는 원 천 코드를 가지 고 모든 
해커들과 PC 애호가들이 코드를 보고 그것을 해석하기 시작하였다. 

많은 사람들이 자기들의 의견을 리누스에게 보내기 시작하였으며 리누스는《사무》 
참조 Linux 원 천코드개 발나무를 발족하였 다. 

그들이 보낸 코드에 대 한 의 견을 받으면서 리누스는 그 의 견을 거의나 접수하지 않 
았으나 일부 사람들은 공동개발자로 되였다. 

첫 제품의 관본이 공개되기전에 3년이상이나 이러한 방법으로 개발이 계속되였다. 

1994년 3월 에 판본 1.0 이 리용할수 있도륵 만들어 졌 다. 그러 나 이 판본은 여 전히 이 
모저모로 산만하고 변덕 스러 워 잘 리용할수 없 었 다. Linux 1.0 은 TCP / IP , SLIP 그리 고 인 
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쇄기 등을 지 원할수 있도록 특색 있게 구성되 였으며 리용가능한 넓 은 범위의 PC 장비들을 
지원할수 있는 구동기들을 충분히 갖추었다. 

그후에 실질적으로 Linux 바람이 불기 시작하였으며 세계의 여기저기에서 수백만의 
애호가들이 체계를 리용하기 시작하였다. 좀 더 일찌기 1992-1993 년경에 첫 Linux 《배 
포판》이 줄현하였 다. 

완전히 기 능적 인 OS 를 제 공하는 제 1차적방법 으로서 배 포판은 Linux 핵 심 부， X 원도우 
즈체 계 그리 고 완전한 응용프로그람과 편의프로그람들을 포함하고 있 었 으며 그 종류는 
수백가지에 달하였다. 

배포판은 또한《설치자》를 포함하며 설치자는 OS 의 2진이메지를 준비하고 기동/차단 
서술과 모든 구성요소들의 호환성을 보장하고 서로 전환할수 있게 준비되였으며 문서로도 
제공되 였다. 오늘날에는 널리 배포되고 있는 RedHat , SuSE 그리 고 Caldera 와 같은 완전히 
성공적 인 수많은 배포판들이 나왔다. 

현재 개 발된것 들을 소개한다. 

1991.8 판본 0.01 

1991.10 사무용공개 0.02 

1993.11 핵 심 부 0.99 를 포함하는 첫 슬래 크웨 어 ( Slackware ) 배 포판 

1994.3 판본 1.0 

1995.6 처음으로 Alpha 구성 방식 에 이식 

1996.10 Debia Linux 가 궤 도에 있 는 스페 이 스샤틀 (space shuttle ) 에 리 용 

1999.1 관본 2.2.0 

2001.1 Linux 2.4.0 발표 

2001.7 Linux 2.4.6 발표 

현재 Linux 에 의하여 제공되는 기능 


Linux 는 1991년에 초라하고 보잘것 없는 상태에서 출발하여 지금까지 많이 갱신되여 
왔다. 공개원천에 대한 인식이 더 넓게 확대됨에 따라 보다 많은 사람들이 Linux 핵심부 
와 부분체 계 에 기 여하게 되 였 다. 

동시 에 수천개 이상의 사용자구역프로그람들이 날을 따라 빈번히 보충되 였다. 

World Wide Web 의 병행적인 증가에 따라 어떤 Web 싸이트들은 Linux 에서 리 용할수 
있는 새 로운 쏘프트웨 어판본들에 대 하여 단독으로 매 일 공개하는데 리용되 고 있 다. 현재 
Linux 는 Intel , Sparc , Alpha , Mips , Motorola 68000 계 렬， PowerPC 를 포함하는 많은 가동환 
경 에서 리용할수 있다. 

초기 에 Linux 는 POSIX (Portable Operating System Interface 휴대 용조작체 계 대 면부)표준 
과 일치되였다. 

이러한 Linux 의 유연성은 Linux 에서 개발된 응용프로그람들과 다른 POSIX 호환조작 
체계들에 아주 쉽게 이식될수 있게 하였다. 

인텔 ( Intel ) 계 렬 CPU 에 기초한 체계 들에서 Linux 2 진파일들은 iBSCS 표준에 맞게 되 여 

있 다. 
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실례로 정적으로 련결된 프로그람이 Free BSD 나 Solaris 우에서 재를파일이 없이 실 
행될수 있게 한다. 

기술적 으로 Linux 는 다음과 같은 기능들을 제공한다. 


▼ 다중사용자 

• 다중프로쎄스 (Multi-process), 다중처리기 (SMP) 

• 프로쎄스조종 

• POSIX 형식의 말단관리 

• TCP/IP, Ipv4, Ipv6 

• 광범하고 다양한 하드웨 어지원 

• 선 택 적 LRU 알고 리 듬과 페 지 coloring 에 의 한 폐 지 화요구 

• 페 지 교환법 (swapping) 

• 캐쉬 

• 동적 및 공유서고 

▲ 각이한 파일 체 계 (ext2fs, UFS, NTFS, HPFS, MS-DOS ISO9660, Coda 등)의 지 원 

랙심부 2. 4의 새로운 기능 

Linux 2.2 는 Linux 2.0 과 Linux 1.x 계 렬에 비 하여 상당한 정 도로 개선되 였 다. 이 체 계 
는 새로운 파일체계들을 지원하고 새로운 파일에 대한 캐쉬체계를 가지고 있었으며 확대 
및 축소가능하였다. Linux 2.4 는 이러한 개선된 측면들로 구성되여 있으며 지금도 여전히 
여 러 가지 다양한 환경 에서 더 좋은 Linux 의 핵 심부로 발전하고 있다. 

가상파일체계 (VFS) 층도 역시 초기의 Linux 판본들로부터 커다란 변화를 이룩한 측면 
의 하나이다. 

Linux 2.2 의 수많은 놀라운 변화가 이 VFS 계 층에 의 하여 특징 지 어 지 는데 이 YFS 
는 캐쉬의 성능을 더 욱 높여 총체적 으로 체계의 성 능을 보다 효과적 으로 향상시키 고 
있 다. 

그러나 Linux 2.2 에서 체계는 아직도 Linux 2.4 시대에 와서야 해결된 적지 않은 중요 
한 제한성을 가지고 있었다. 

Linux 2.2 가 체계를 조종하는 방법에서 한가지 중요한 제한성은 캐쉬에 대하여 2 개 
의 완충기 를 사용하는것이 였 다. 

즉 입력용완충기와 출력용완충기를 사용하였다. 쉽게 생각해 볼수 있는것처럼 이것 
은 핵 심 부개 발자들이 필요할 때 마다 이 캐쉬 들이 동기 상태 에 있는가를 항상 확인한후 코 
드화를 해 야 하므로 작업 이 매우 복잡해 지군 하였다. 

Linux 2.4 에서는 다중캐쉬체계를 없애고 모든 작업을 단일한 캐쉬층에서 진행 하게 
함으로써 이 러한 복잡성을 완전히 없애 버리였다. 

이러한 변화는 Linux 2.4 를 보다 효과적으로 되게 하였으며 이로 하여 코드는 개발 
자들에게 더 리해 하기 쉬워 지 고 캐쉬 에 요구된 기 억의 크기도 크게 두개 로 나누어 지게 
되였다. 
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이러한 재기록과정에 많은 경쟁조건(보호되지 않은 변수에 대한 접근시 다중처리 
《경쟁》에서 발생되는 오유)이 해소되였으며 코드는 최신식의 체계로 확대축소가능하게 
할수 있게 간결 해 졌고 다중기록권 (Multiple Volumes ) 을 포함하는 디스크의 속도는 훨씬 
더 빨라 지게 되 였다. 

Linux 의 핵 심 부는 장치구동기，규약 그리 고 다른 형 태의 구성 요소들을 포함하는 모 
둘화된 요소와 부분체계들의 집합이 다. 이 모둘화된 부분체계들은 Linux 핵심부를 확장할 
수 있는 표준적 인 방법 을 제 공하는 응용프로그람작성대 면부 ( API ) 에 의하여 Linux 의 핵 심 
부에 추가된다. 이 핵심부의 대부분의 내용들은 Linux 에서 가장 중요한 동작을 하는 
Linux 조작체 계 구성 요소들에 주목되 고 있다. 핵 심부 2.4 계 렬 에서 Linux 는 수많은 프로쎄스 
와 과제 를 조종할수 있도록 그 능력 이 방대하게 개 선되 였 다. 과제 의 한계 는 현재 4090개 
이상으로 높일수 있게 되 였다. 게 다가 과제 관리 기 ( scheduler ) 의 효과성 이 상당히 개선되 였 
는바 Linux 2.4 는 그 이 전의 판본들보다 더 많은 병 행프로쎄 스들을 더 훌륭히 조종할수 
있게 되였다. 

Linux 2.4 는 또한 이전의 Linux 핵심부에서 조종할수 있었던것보다 훨씬 더 많은《엔 
터 프라이 즈급》의 하드웨 어 들을 조종할수 있 다. 

실례로 Linux 2.4 는 정교한 검사수정 ( patch ) 들로 4 GB 이상의 RAM 을 주소화할수 있다. 

어 떤 기계 에서는 12 GB 의 RAM 을 배 치구성할수 있으며 한개의 상주주소화공간의 크 
기가 8.3 GB 되는것도 있다. 

SMP 체계우에서의 축소확대기능은 현재 독자적지위에 있는 조작체계들과 비슷하며 
어떤 경우에는 그것들을 릉가하고 있다. 

다른 가동환경 ( platform ) 을 지원하는 기능도 역시 높아 지고 있 다. 전통적 인 구성 방식 
에 이 어 Linux 2.4 는 현재 Transmeta Crusoe Processor 를 직 접 지원한다. 또한 3 Com Palm 
Pilot 뿐아니 라 Psion 5 등은 모두 특정 방식 에서 Linux 를 실행 할수 있다. 새 로운 인텔 IA 64( 다 
음세대 인텔 i 86 계렬의 64 bit 처리기)는 아직 직접적으로 핵심부에 포함되지 않고 있다. 

새 로운 파일 체 계 지 원기 능이 계 속 보충되 는 한편 (Irix efs 파일 체 계 와 DVD 디 스크에 리 
용되 는 UDF 표준) 다른것들은 계속 쓸모가 없어 진다 ( QNX 나 extl ). 

저준위중단을 조종하는 새 로운 혁 신적방법 의 하나인 tasklet 의 도입 은 보다 많은 
TCP / IP 탄창을 효과적으로 제공한다. 

표준 DECNet 를 조종할수 있는 새로운 망규약프로그람이 추가되였다. 

Linux 2.2 와 Linux 2.4 에는 쟈바 ( Java ) 응용프로그람이 실행될 때마다 자바인터프레터 
(존재하는 경 우)가 출발하는 내 장지 원기 능이 포함되 여 있 다 ( Linux 는 핵 심 부준위 에 서 이 것 
을 실현할수 있는 첫 조작체계의 하나였다.). 

Linux 2.4 는 여전히 필요할 때마다 자바인터프레터의 적재를 지원하는 기능을 포함 
하고 있지 만 정의 된 자바구동기는 제거 되 기때 문에 사용자는 《 Misc 》 구동기 를 리용하기 
위 하여 그것 의 배 치 구성 ( configuration ) 을 갱 신해 야 한다. Linux 2.4 핵 심 부는 핵 심 부 Web 데 
몬 (kernel web daemon ) 이 나 혹은 kHTTPd 를 포함한다. 

이러한 기술은 정적인 Web 페지를 보다 효과적으로 조종할수 있게 한다. 이 장의 서 
두에 서 우리 는 우에 서 서 술한것 처 럼 Linux 에 서 개 선되 고 강화된 모든 부분들과 상세한 측 
면들을 고찰하게 될것 이며 그것 에 포함되 여 있는 핵 심부의 동적특성 을 알게 될것 이 다. 
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제 2 장. 랙심부의 콤파일 

이 책에서 론의되는 많은 파일체계들은 핵심부 ( Kernel ) 를 재를파일할것을 요구한다. 

어 떤 경 우에 는 우선 핵 심 부를 새 로운 파일체 계쏘프트웨어 로 대 치할것 을 요구한다 
( JFS , ReiserFS , XFS ). 

그러므로 여 기서는 요구되 는 기능들로 새 로운 핵 심부를 어 떻게 만드는가를 총체적으 
로 리해하는것 이 아주 중요하다. 새 로운 핵 심 부를 콤파일 하고 설 치하는 작업 은 많은 사 
람들에게 조작을 틀리 게 하여 콤퓨터를 기동하지 못하게 될것 같은데 로부터 위험 하고 조 
심스러 운 일처 럼 보이 고 있다. 모든 체계관리기과제 에서 와 같이 부정 확한 방법 으로 어떤 
작업 을 진행하면 무슨 사고가 날지 모른다. 그러 므로 설 치 작업 을 한 다음 새 로운 핵 심부 
를 콤파일하는것 이 제 일 좋다. 

만일 어떤 작업을 틀리게 하면 체계는 시간을 많이 소모함이 없이도 스크래치로부터 
재설 치될수 있다. 

틀린 작업 을 계 속 하면 나중에 보충적쏘프트웨어 를 설 치한후(자료기 지관리기 와 같은) 
더 큰 고통을 받게 될것 이 다. 그러 나 걱정할 필요는 조금도 없다. 핵심부의 콤파일과 설 
치는 생각한것보다는 훨씬 단순하다. 표본핵심부를 콤파일하는 단계를 다음에 보여 준다. 

원천쿄드의 나무구조 

이 책 을 보다 더 잘 리해할수 있 을뿐아니 라 핵 심 부를 검 사수정 하고 그것 을 콤파일할 
수 있도록 하기 위하여서는 원천코드의 나무구조에 대한 표상을 잘 가지는것이 중요하다. 


卜 Documentation 
I — arm 

、 一 nwfpe 
j— cdrom 
! … fb 

j — filesystems 
1-- i386 
!--- isdn 
i … kbuild 
I … m68k 
!--- networking 
\ — ip_masq 
!--- powerpc 
!--- sound 
I — sysctl 
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--- video 41 inux 










--- icn 
isdnloop 
… pcbit 
\ --- sc 

… macintosh 
一 - misc 
—— net 
… fc 

— hamradio 

I 一 - soundmodem 
\ — irda 

— nubus 
… pci 

pnp 
一 - sbus 

I 一 - audio 
\ 一- char 
一 - scsi 

\ 一 - aic7xxx 

— sgi 

\ 一 - char 
一 - sound 

\ 一 - lowlevel 

— tc 

— usb 

\ 

—— maps 
--- video 
\ — zorro 
fs 

一 - adfs 

— affs 

— autofs 
一- coda 

|— devpts 

— efs 
一 - ext2 

— fat 
一 - hfs 
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… hpfs 

— isofs 
--- lockd 
一- minix 

— msdos 

— ncpfs 

— nfs 
--- nfsd 

— nls 

— ntfs 
--- proc 

— qnx 4 
--- romfs 
--- smbfs 

— sysv 

— ufs 

— umsdos 
、 — vfat 

|— ibcs 
--- Doc 

—- PROD . Patches 
一- Patches 
--- Tools 
— VSYS 
--- devtrace 
--- iBCSemul 
\ --- maps 
--- include 
| -一 ibcs 
\ — x 286 emul 
|— include 

--- asm - > asm - i 386 


asm - i 386 

linux 

I ― byteorder 
I 一- lockd 
I 一- modules 
I --- modules-BOOT 
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I 一- modules-smp 
I 一- modules-up 
I — nfsd 
I 一- raid 
\ --- sunrpc 
net 

\ — irda 
--- scsi 

I 、 一 video 
--- init 

— ipc 

— kernel 

— lib 

— mm 

--- modules 
一- net 
― 802 

I 一- pseudo 
\ 一- transit 

— appletalk 

— ax 25 
一- bridgs 
—— core 

— decnet 

— econet 

— ethernet 

— ipv 으 
一- ipv 6 

— ipx 

— irda 

I — compressors 
I 一 ircomm 
I --- irlan 
、 irlpt 
… lapb 
--- netlink 
—— netrom 
… packet 
| --- rose 




| --- sched 
—— sunrpc 
… unix 
… wanrouter 
x 25 

一- pcmcia - cs -3.0.14 



doc 

etc 


k 一- cis 


flash 
include 
I — linux 



Linux 가 구성방식의존코드와 비의존코드로 어떻게 구성되여 있는가를 잘 아는것 
이 중요하다. 핵 심 부원천의 95%는 비 의존코드이 며 따라서 Linux 의 모든 이 식묶음과 
정 확히 같다. 나머 지 5%는 보통 아쌤 블러코드나 시 계박자주파수와 같은 작고 상세한 
것들이 다. 

arch / 등록부 

이 등록부는 구성 방식 에 의 존하는 코드가 위 치 하는 곳이 다. 

이 등록부아래 에는 Linux 의 매 이 식묶음에 대 하여 3개 이상의 부분등록부 ( kernel /， lib /， 
mm /) 들이 존재 한다. 

kernel 부분등록부는 신호조종，시 계 조종 등과 갈은 일 반 핵 심 부특유의 구성 방식 의 존 
실현부가 포함되여 있다. 

lib 부분등록부에 는 구성 방식의 존원천코드로부터 콤파일되 면 더 빨리 실행 되 는 국부 
적 인 서 고함수들이 차례 로 포함되 여 있 다. 

mm / 등록부는 국부기억조종실현부를 포함한다. 
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drivers / 등록부 


모든 구동기 의 원천코드는 이 등록부에 있다. Linux 2.4 가 지 원하는 장치 의 종류가 
아주 다양하므로 이 등록부에는 많은 원천코드들이 포함되는데 실례로 모든 핵심부원천 
코드의 50%이 상을 차지한다. 

fs / 등록부 

fs / 등록부는 파일 체 계 를 지 원하는 코드들을 모두 포함하는 등록부이다. IBM 의 JFS 나 
Hans Reiser 의 ReiserFS 와 같은 새로운 파일체계를 실현하려는 사람들은 해 당 파일체계를 
위한 원천코드들을 포함할수 있도륵 이 등록부를 검 사수정하여 야 한다. 

include / 등록부 

새로운 핵심부를 실제적으로 콤파일하기전에 반드시 배치구성이 되여야 한다. 배치구 
성 ( configuring ) 은 어 느 구동기 나 속성 그리 고 어 느 모둘을 핵 심 부에 콤파일 할것 인 가를 제 작 
편의프로그람에 통보해 준다. 대 다수의 표준배 포판들은 암시적 으로 단일처 리기용핵 심부로 
되 여 있다. 핵심부를 표준 SMP 속성으로 실현하려면 SMP 에 따르는 배 치구성 이 요구된다. 

ipc / 등록부 

프로쎄스들간 통신을 조종하기 위하여 필요한 모든 코드들이 이 등록부에 보관된다. 
중요한 모든 쎄마포-조종용 C 코드 ( sem . 功도 바로 여기에 포함된다. 

그럼 에 도 불구하고 이 등록부는 코드의 크기 가 3751행밖에 되 지 않는다. 

init / 등록부 

fork () 를 실현하기 위한 코드와 흔히 실행되는 코드부분으로서 cpu _ idle () loop 와 같은 
많은 중요한 코드를 포함하는 Main . c 가 바로 init / 등록부에 있다. 

기동할 때 bogomips 를 생성 하는 코드가 여기 에 존재 하는데 그 코드들은 처 리 기의 속 
도지시 를 관측한다. 실제 적 인 처 리 기의 속도는 측정하지 못한다. 


void_init calibrate_delay(void) 

{ 

unsigned long ticks, loopbit; 
int lps_precision = LPS_PREC; 

loops_per_sec = (1«12) ; 

printk ( “Calibrating delay loop... ” ) ; 
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while (loops_per_sec << = 1) { 

/* wait for “start of” clock tick */ 

ticks = jiffies; 

while (ticks = = jiffies) 

/* nothing */; 

/* Go . . */ 

ticks = jiffies; 

_delay(loops_per_sec); 
ticks = jiffies - ticks; 
if (ticks) 
break; 

} 

lib / 등록부 

이 등록부에는 종종 핵심부의 다른 부분에서 요구되는 코드들이 존재한다. 실례로 
inflate.c 를 여기서 찾아 볼수 있다. 

이 코드는 기 동시 에 핵 심 부의 압축을 해 제 하고 그것 을 기 억 에 적 재 시 킨 다. 

표준 PKZIP 압축알고리 듬을 리용하여 어 떻게 압축을 해제하는가에 대 해서는 이미 
알고 있을것이다. 

kernel / 등록부 

이 등록부에는 제일 빈번히 호출되는 핵심부함수들중에서 그 일부가 존재하고 있다. 
스케줄러 (Scheduler) 외에 fork() 와 timer.c 도 여기에서 찾아 볼수 있고 printk.c 도 이 등록부 
에 서 찾을수 있 을것 이 다. 

핵심부코드전반에 걸쳐 printk() 는 printf() 함수가 핵심부로부터 호출될 때에는 SMP 기 
능을 수행하지 못하기 때 문에 printf() 대 신에 printk() 를 리용한다. 

따라서 서 로 다른 CPU 우에서 동작하는 여 러 가지 과제들은 동시에 출력을 보장하면 
서 조종대 나 체 계 가동일 지 등록부에 써 넣 을수 있 다. 

mm / 등록부 

mm 은 기 억관리 (memory management)-!- 의 미한다. 

이 등록부는 Linux 핵 심 부에서 가상기 억관리 를 실현하기 위한 원천코드들을 포함한다. 

net / 등록부 

TCP/IP, Netware, Appletalk 와 같이 망을 지원하는 모든 코드들은 이 등록부에 보관 
한다. 


20 




핵심부의 콤파일 


실천적으로 핵심부를 콤파일하기에 앞서 콤파일편의프로그람에 어느 기능이 요구되 
며 구축된 그러한 기능들을 핵심부에 포함시키겠는지 혹은 그것들을 적재가능한 모둘로 
배치구성하겠는가를 알려 주어야 한다(핵심부가 적재가능한 모둘들을 어떻게 관리하는가 
에 대해서는 다음에 고찰한다.). 

다음 표는 핵심부를 콤파일하는데 어떤 명령들이 사용되는가를 보여 준다. 


형 

명 령 (root) 

Text prompt 

Text menus(ncurses style) 

GUI 여실 행 요구 ) 

make config 
make menuconfig 

Make xconfig 


Make config 는 선행 한 선택 항목을 기 억 하므로 언제 나 그것 을 다시 출발시 킬수 있으 
며 필요할 때마다 변경시킬수 있다. 핵심부가 만족스럽게 배치구성되면 콤파일처리를 진 
행할수 있 다. 


root@maguro/usr/src#make dep; make clean; 
make bzImage; make modules-install 

명령 “make bzlmage” 는 핵심부를 를파일하고 arch/i386/boot 등록부에서 bzlmage 를 
호출한 파일을 남겨 둔다. 우의 명령을 단계적으로 진행하는데는 일정한 시간이 걸린다. 

512MB RAM 을 가진 2 중 PIE 700MHz CPU 상에서 이 명령은 약 4min 정도 걸리는데 
속도가 더 뜬 콤퓨터 에서는 더 오랜 시간이 걸린다. 이제 새 로운 핵심부를 설치해 보겠 
다. 많은 사람들이 핵 심 부설 치 에 LILO(Linux Loader : Linux 적 재 기 )를 리 용한다. 

명 령 make bzlilo 는 핵심부를 설치 하고 그우에서 LILO 를 실행시키며 기동에 필요한 
모든 준비를 갖출수 있게 한다. 그러나 이 조작은 LILO 가 해당 체계에 다음의 방법으로 
배치 구성될 때에만 가능 하다. 즉 핵심부 /vmlinuz 가 /sbin 에 있으며 lilo config (/etc/ 
lilo.conf) 가 이것과 호환되는 경우에만 가능하다. 

다른 한편 lilo 등록부도 리용해 야 한다. lilo 를 리용하여 설 치 작업 을 진행하는것 은 
아주 명 백 하고 쉬 운 프로그람이지 만 그 배 치구성파일 을 가진 사람들은 혼돈될 경 향성 
도 있 다. 이 제 config(/etc/lilo/config (변경 된 판본)이 나 혹은 /etc/lilo.con (새 판본))파일 을 보 
고 현재의 설치가 어떤 동작을 수행하는가를 알아 보자. 

Config 파일은 아래와 같이 되여 있다. 

image=/vmlinuz 
lable=Linux 
root=/dev/hdal 
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“image=” 는 현재 설 치된 핵 심 부에 설정된다. 많은 사람들은 /vmlinuz 를 리용한다. 
“lable” 은 기동할 핵 심 부가 조작체 계 를 결정 할수 있도록 LILO 가 리 용하는 기 호이 며 
“root” 는 특정한 조작체 계 의 /등록부이다(뿌리등록부). 

변경된 핵심부의 여벌 복사 (bakcup) 를 진행하고 지정 한 장소에 생성 해야 할 bzlmage 
를 복사한다(만일 /vmlinuz 를 리용하면 cp bzImageAvmlinuz 로 할수도 있다.). 

LILO 를 재 실 행 하고 핵 심 부를 기 동관리기 (boot manager) 에 첨 가한다. 다른 한편 새 
토운 핵 심 부를 LILO 배 치구성 에 실제 적 으로 넘 겨 주기전에 검 열을 위한 기동디 스크를 
만들려 고 하면 많은 배 포판들과 함께 배 포되 는 mkbootdisk 편의 프로그람을 리 용할수 
있 다. 

GNU gcc 콤파일러 

Linux 핵 심 부는 GNU gcc 콤파일 러용으로 서 술된 다. 그러 므로 어 떤 다른 C 를파일 러 를 
가지 고 핵 심부를 콤파일 하려 고 하면 완전한 오유를 산생 시킬수 있다. 

원천코드는 아무 를파일 러 나 리용하는 현상을 막고 gcc 콤파일 러 를 사용하려 는 의 미 
에서 완전한 gcc 정의명령들로 구성된다. 이러한 gcc 와의 관계때문에 핵심부원천코드는 다 
른 C 콤파일러를 개발리용하는 사용자들에게는 좀 이상한 감촉을 가지게 한다. 이러한 느 
낌 을 없애 는 하나의 공통적 인 특수한 표현법 이 “inline functions” (직 결기 능)를 리 용하는 
것 이 다. 

직결기능은 단일한 함수 즉 호출함수의 참조시 매번 함수호출을 실행할 대신 그 매 
개를 재현하는 방법으로 호출함수를 완전히 확장하는 gcc 콤파일러에 대한 명령이다. 어 
떤 경우에는 이것이 이식가능한 코드를 엄는것을 불가능하게 하는 객체도 될수 있다. 그 
러나 이것은 사실상 경우에 맞지 않는다. Linux 의 gcc 름파일러는 Linux 가 이식될수 있는 
모든 가동환경 에 존재 하기 때 문에 코드는 이 러 한 구성 방식 으로 얼 마든지 이 식 할수 있 다. 
물론 다른 C 를파일러에서 정확하게 콤파일될수 있다는 견지에서는 이식이 불가능하다. 
다시 말하여 핵심부가 구성 방식과 를파일러를 초월하여 이식성을 요구한다는것은 아니 다. 
Linux 핵심부는 믿음성과 효과성을 목적 으로 최 량화되며 이 두가지 목적은 두말할 여지없 
이 아주 중요한 내용으로 된다. 

쿄드화관례 

이 책을 읽은후에는 Linux 핵심부에 기여할 생각이 있으리 라고 본다. 그 어떤 관례를 
존중하는 조건에서는 설명 이 항상 /* */ 의 기호로 표현되며 이것은 한행에 대해서도 허 
용된다. //의 해 설표시 는 허 용되지 않는다. 

흔히 함수에 리용되는 열린괄호 ( { ) 는 분리행우에 있게 된다. 

명 령문은 다음과 같은 방법으로 코드화된다. 

If (str[0]>='0' && str![Q]<='9 , ) { 

Strcpy(name, “ttys” ) ; 
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Strncpy(name+4, str, sizeof(name)-5); 

} else 

strncpy(name, str, sizeof(name) - 1); 
name[sizeof(name)-1]=0; 

명령문인 경우에는 단일행도 허용된다. 

if (! s 仕 cmp(str, “ttya” )) s 仕 cpy(name, “ttysO” ) ; ne ifs are quite ok ; 

이 전시 기 부터 이 미 핵 심 부원천코드에는 항상 goto 문이 많이 리용되 였 다. Linux 도 례 
외가 아니다. Linux 도 약 80 개 행의 코드마다에 goto 문이 한개정도 포함된다. 이것은 프로 
그람작성 에서 속도가 떠지게 하는것 이 아니 라 오히 려 속도가 빠른 코드를 작성 하기 위하 
여 제기된 요구이기도 하다. 반복화된 순환명령문에서는 정지명령문보다 오히려 코드를 
줄이 기 위하여 goto 를 리용하는것 이 훨씬 쉽다. 

구성방식의존성 

Linux 는 광범하고 다양한 처리기가동환경에서 실행된다. 거의 매달 다른 구성방식에 
대 하여 새 로운 이식 을 성 공적 으로 진행한 자료들이 보고되 고 있다. Linux 가 B86 처 리 기 
우에서 시작되였다는데 대하여 강조한다. 

이것은 핵심부코드의 어느 곳에서나 명백히 찾아 볼수 있다. 

다음의 표는 지 금까지 달성한 이 식 상태 를 보여 준다. 


처 리 기 형 

비 트길 이 

주장자 

Intelx86 

32 

리누스 토발즈 

Crusoe 

32 

리누스 토발즈 

MIPS 

32/64 

알란 콕스 

IA64 

64 

트릴리 안 대상과제 

PA-RISC 

64 

푸핀 그룹 

Alpha 

64 

리챠드 헨더슨 

ARM 

32 

루쩔킹 

Sparc 

32/64 

데 이 비 드 . 에 쓰 . 밀 러 

PPc 

32 

코트 다우겐 

M68000 

32 

제스 쏘렌센 
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제 3 장. 파일체계란 무엇인가 

이 장에서는 파일체계의 구성성분들이 무엇으로 이루어 지며 그것들이 어떻게 Linux 
2.4 에 서 실현되 는가에 대 하여 고찰한다. 일 반적 으로 다른 UNIX 파일체 계 에서 설정한 대 부 
분의 내용들이 Linux 에서도 역시 유효하다. 그러 나 일부 경우에는 Linux 가 오히 려 UNIX 
보다 구성 방식비의 존성，속도，효과성，안전성 그리 고 실 현의 정 교성 을 보다 쉽 게 할수 
있는 여유를 가지고 있다. 


파일체계의 일반적형식 

이 장의 구성부분은 오스트랄리아의 네일즈 브라운의 Linux 가상파일체계에 대한 중 
요한 문서를 기초로 하여 이루어 졌다. 

파일 체 계 는 를퓨터 의 하드디 스크가 국부디 스크든지 망을 리용하는 기 록권 이든지 혹 
은 저장망 ( SAN ) 의 외부공유디스크든지 관계없이 자료를 기억시키거나 검색하기 위한 조 
작체계의 론리적수단이 다. 특히 파일체계는 UNIX 양상의 OS 에 요구되는 기본적 인 조작을 
실현하고 있다. 

▼ 파일을 생성하거나 삭제한다(즉 기억매체우에서 공간의 배정 및 해제). 

• 읽 기 및 쓰기를 위한 파일의 열기 

• 파일 안에서의 찾기(주의 : Linux 는 파일 레코드의 표기를 위 한 핵심부준위에서의 
지원은 제공하지 않는다.) 

• 파일의 닫기 

• 파일 의 그롭을 구성 하기 위한 등록부의 생 성 

• 등록부내용의 목록표시 

▲ 등록부로부터 파일의 제거 

이러한 기능들을 현대적인 UNIX 환경으로 우리가 일반적으로 알게 되기까지에는 여 
러해의 발전과정 을 거 치였으며 복잡한 파일관리능력 과 자료관리대 면부의 값 눅은 모임으 
로 제공되고 있다. 

처음부터 Linux 는 사용자들이 하나이상의 파일체계를 쓰는데 적응시키 려고 노력하여 
왔다. 사실 사용자가 DOS 나 FAT 32 와 같은 다른 디스크우에 하나이 상의 Linux 구획 이 아 
닌 구분구역을 가지게 하는것은 일반성 이 없었다. Linux 우에 이 기록권 ( volume ) 들을 올려 
태 우기 ( mount ) 하려 고 하면 그 핵 심 부에 적재된 DOS 나 FAT 32 파일체 계 가 있어 야 하였다. 
그러 므로 Linux 개 발자들이 핵 심부와 잠재 적 으로 많은 파일체 계 실현사이의 호상관계 를 단순 
화하려고 한것은 론리적이였다. 따라서 그들은 Linux 가상파일체계 ( VFS ) 를 생성하게 되 
였다. Linux VFS 는 ext 2, DOS , FAT 32, OS /2, HPFS 와 다른 체계에서와 같은 실제적인 
파일체 계우에 있는 추상적 인 층이 다. Linux VFS 에 의 하여 사용자프로그람들은 구획우 
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에서 리용되는 파일체계에 대한 구체적특성들을 알지 못해도 되였다. 

즉 체계호출이 항상 같았기때문에 기본기능(지우기，복사，생성)은 언제 나 동일하 
였 다. 

다음에는 VFS 기 본기능들을 적 응시키 고 그것들을 파일체 계의 규약과 정의 에 따라 수 
행하게 하는것 이 파일체 계실현의 중요과제 였 다. 

그러므로 Linux VMS 는 DOS , OS /2, FPFS 나 JFS 51:1 구획 에 관계 없이 파일을 편집 하기 
위한 표준 “Vi mgfile . foo ” 을 생성해낼수있게 하였다. 이제 파일체계에 대한 폭넓은 
개념을 다시 고찰해 보겠다. 파일은 단순히 요소들의 순서화된 렬이며 여기서 요소들은 
장치적실현에 따라 기 계단어 들로 될수 있고 문자나 혹은 비 트들로 될수도 있다. 프로그 
탐이 나 사용자는 파일 체 계 를 리용해 서만 파일 을 생 성하거 나 변경하거 나 지 울수 있 다. 

일반적으로 UNIX 계렬에 대해서는 파일체계의 준위에서 파일이 양식화* 2 ( format ) 되 
지 않고 있 다. 모든 양식 화는 보다 높은 준위 의 모둘 혹은 요구한다면 사용자지원프로그 
람에 의하여 실현된다. 특정한 사용자에 게 있어서 한개 파일은 하나의 이 름을 가지며 그 
이름은 기호적표기로 된다(기호적이름은 어떤 한계까지의 임의의 길이로 될수 있으며 그 
자체의 고유한 문장구조를 가진다.). 

사용자는 기 호적파일 이 름과 파일안의 요소에 대 하여 선형 적 인 첨 수를 정 의하여 파일 
안의 요소를 참조할수 있다. 

고준위모둘을 리용하여 사용자는 역시 문맥 에 따라 직 접적 으로 적 당히 정의된 요소 
의 렬을 참조할수도 있다. 

등록부 ( directory ) 는 파일 체 계 에 의 하여 유지 보존되 며 입 구점 ( entry ) 의 목록을 포함하는 
득수한 파일 이 다. 

사용자에 게 는 입 구점 이 파일 로 나타나며 그것 은 기 호입 구점이 름에 의하여 접 근되 는 
데 이 때 기 호입 구점이 름은 사용자의 파일 이 름으로 된 다. 

입구점이름은 그것이 생성되는 등록부안에서만은 유일해야 한다. 그러므로 UNIX 에 
서와 Linux 에서 파일이름공간의 범위는 한개 등록부로만 간주된다. 실제적으로 매개 입구 
점 은 지 적 자로 구성 되 는데 지 적 자의 종류는 2가지 이 다. 

입구점은 어느 한 파일을 직접적으로 지적하거나(파일 그자체가 등록부일수도 있다.) 
아니 면 같거 나 혹은 다른 등록부안의 어 떤 다른 입 구점 을 지 적할수도 있 다. 

다른 등록부입 구점 을 지 적하는 입 구점 을 련결 ( link ) 이 라고 부론다. 련결과 관련된 정 
보만은 그것 이 련결하는 입 구점 에 대 한 지 적 자이 다. 이 지 적 자는 계 층안에 련결된 입 구 
점 을 유일적 으로 식 별하는 기 호이 름에 의하여 정의된다. 

련결은 그것 이 효과적 으로 지 적하는 가지 로부터 의 접 근조종정 보를 관리한다. 


J 的는 IBM 실 행 기 록파일 체 계 이 다. 

다른 많은 조작체계들은 파일내용의 양식화를 위한 자체의 표식을 가지고 있다. 실례로 IBM 
OS /390 에는 고정된 레코드와 변하는 레코드에 대한 서로 다른 양식이 있다. UNIX 는 단순성을 
위하여 파일내 용의 양식 을 파일 체 계 가 알지 못하게 하는 방법 을 택하고 있 다. 
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한 등록부안에서 직접적으로 지적된 파일은 그 등록부에 대하여 직접동 
지적한 등록부는 파일에 대한 직접상위이다.). 

그자체가 두번째 등록부에 대하여 직접하위인 등록부에 대하여 또 직접 
은 두번째 등록부에 대 하여 서 도 하위 이 다(류사하게 두번째 등록부는 파일 에 
이 다.). 

뿌리 ( root ) 는 령 준위 를 가지 며 그것 에 대 하여 직 접하위 인 파일 은 1준위 i 
을 확장하면 하위 성 (상위 성 )은 직 접하위 (상위 )파일 사슬을 거 처 분할되 는 중 
수에 의하여 정의된다(하위성 에 따르는 준위수의 증가에 의하여 지 장을 믿 
경우는 준위수를 부수로 할수도 있다.). 

이때 련결은 독립적이기는 하지만 나무구조우에 덧붙여 지는것으로 고 
상위성이나 하위성의 표기는 련결과는 아무런 관계도 없으며 오직 가지와만 
는데 대하여 강조해 둔다. 이러한 종류의 나무계층구조에서는 사용자가 등톡 
여기저기 움직이는것보다는 하나 혹은 몇개의 등록부에서 작업할수 있다. ^ 
관심을 가지는 사용자들은 공통적인 파일들을 공유할수 있고 또 자기에게만 
인용파일을 가질수 있게 계층이 배렬되는것은 자연스럽다. 

어느 한 순간에 한 사용자가 작업등록부라는 한 등록부안에서 조작하는 
한다. 사용자는 간단하게 입 구점이 름을 정 의 함으로써 작업 등록부안의 입 구 
파일에 효과적으로 접근할수 있다. 

하나이상의 사용자에 대 해서 는 어 느 한 순간에 동일한 작업등록부를 




비종단마디(끝이 아닌 마디)는 등록부파일을 지적하며 한편 그러한 매개 마디로부터 아 
래방향으로 향하는 선들은 그 마디에 대응하는 등록부에서의 입구점(즉 가지)을 지적한 
다. 4각형 으로 표시한 종단마디 (끝인 마디)는 등록부가 아닌 파일 들을 지 적한다. 

문자들은 입 구점이 름을 가리키 며 수자들은 그림 에 서 등록부들을 식 별 하기 위한 서 
술목적으로만 리용된다. 실례로 문자 “ J ” 는 그림안의 서로 다른 등록부들에서의 여 러가 
지 입 구점 들의 입 구점이 름이 며 수자 “0” 은 뿌리 로 간주한다. 입 구점이 름은 그것 이 생 성 
되 는 등록부에 관해서만 의미를 가지며 그 등록부밖에서는 유일할수도 있고 유일하지 않 
을수도 있다. 

여 러 가지 리유로부터 전체 로서 계 층안의 입 구점 을 유일하게 정 의하는 기 호이 름을 
가지는것이 좋다. 

그러한 이 름은 뿌리와 관련하여 지 어 주는데 보통 이것을 나무이 름이 라고 한다. 이 
것 은 뿌리 로부터 가지사슬을 거 처 입 구에 도달하기 위하여 요구되 는 입 구점이 름사슬로 
구성된다. 많은 경우 사용자는 입구점의 나무이름을 알 필요가 없다. 

다른 방법 으로 정 립하여 표현하지 않는 한 파일의 나무이 름은 뿌리 와 관련시켜 정의 
한다. 또한 임의의 등록부에 관하여 유일하게 이름을 정의할수도 있다. 

임의의 이름을 가진 련결은 명 령에 의하여 다른 등록부에 설정될수도 있다. 

ln-s 련결이 ■, 경로이름 

경로이름에 련결할 입구점의 이름은 작업등록부와 관련된 나무이름으로 정의할수도 
있으며 혹은 뿌리와 관련된 이름 혹은 보다 일반적으로 경로이름으로 정의할수도 있다 
(아래에 정의되였다.). 

파일은 거기에 어떻게 접근하는가에 따라 서로 다른 사용자에 대하여 서로 다른 이 
름을 가질수 있다. 

련결은 계층안의 어떤 곳에서나 가지에 대한 지름경로로 봉사하며 사용자에게 그 련 
결이 실제적으로 요구되는 파일을 직접적으로 지적하는 가지라는것을 알려 준다. 

비록 련결들이 가지의 나무구조안에 이미 주어 진 가지에 대한 기본적인 능력을 전 
혀 추가하지 못한다고 해도 파일체계 가 가지들을 리용하는 일을 아주 쉽게 해주게 된다. 

련결은 또한 공유파일들의 2중복사조건도 상당히 감소시켜 준다. 

그림 3-1 의 나무구조에 련결들을 덧붙인것을 그림 3-2 에서 설명하고 있다. 

마디 로부터 아래방향으로 향한 점 선들은 다른 입 구점 과 련결 한 입 구점 을 보여 준다. 
련결들이 나무구조에 보충되 면 방향그라프로 된다(물론 방향은 매 마디 로부터 아래방향 
으로 향한다.). 

그림 3-2 의 실례에서 등록부 2에 G 라는 이름을 가진 입구점은 등록부 3에 C 라는 이 
틈을 가진 가지와 련결된다. 등록부 4에 C 라는 이름을 가진 입구점(등록부안을 제외하고 
는 이 름이 꼭 유일할것 을 요구하지 않는다는 사실 을 상기)은 등록부 2의 입 구점 G 와 련 
결되며 따라서 등록부 3의 C 에 대 한 련결로서 작용한다. 

이 련결 들은 둘다 효과적 으로 등록부 1을 지 적한다. 련결 들을 포함하는 나무이 름과 류 
사한 이 름을 가지는것 이 좋다고 인정된다. 그러 한 이 름이 경 로이름 ( pa 出 name ) 이며 이것은 
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여기서 경로이름은(변경된) 작업등록부 혹은 뿌리와 관련될수 있다. 뿌리와 다른 
-에 관한 경로이름의 정의는 다음의 례외에 따르는 나무이름의 정의와 류사하다. 
-에 대한 직접하위파일의 개념은 입구점에 의하여 효과적으로 지적되는 파일의 y 
- 바뀌운다. 또한 파일에 대한 직접상위등록부에 대한 개념은 우에서 본 효과적인 
卜 즉 등록부가 파일에 접근하기 위하여 이미 먼저 리용된 입구점에 의존하는 지근 
여물형식으로 정의된 개념으로 바뀌운다. 

일반적으로 임의의 파일은 현행작업등록부에 관한 경로이름(사실상 나무이름이나 
1 이름일수 있는)에 의하여 정의될수 있다. 파일은 또한 뿌리와 관련된 경로이름에 
|서도 정의될수 있다. 앞의 경우에 경로이름은 두점으로 시작되며 뒤의 경우에는 
되지 않는다. 

과일체계에서의 객체 

우리의 경우에 파일체계는 객체를 담아 두는 저장통으로 고찰할수 있다. 

여기에서 객체들은 파일체계가 사용자에게 추상화하여 제공한 모든 론리적실체로 
파일체계에서 한가지 명백한 객체의 실례는 파일이며 다른것은 객체로 된다. 

례하면 다른것 들은 아직 기 호적이 름에 불과하며 사용자는 상위블 로크， 색 인마 C 
말단사용자의 눈에는 직접 보이지 않는 객체를 가지게 된다. 




파일체계와 Unux 와의 관계-가상파일체계 

UNIX 체계에서 많은 파일들은 수백，수천 혹은 그이상으로 쉽게 배렬되기때문에 파일체 
계조종구조를 조작하는 과제가 응용프로그람과는 분리되며 엄밀하게 말하여 아직은 핵심부 
요소로 되지 않는다. Linux 핵 심부의 파일부분체 계 (file sub system ) 는 파일 이 어떤것 인가에 대 
한 특수한 추상적표상을 준다. Linux 자체 고유의 ex 任 혹은 proofs , ReiserFS 그리고 다른 파일 
체계들에서 구체적 인 내용은 알수 없고 모든 파일체계는 동일하게 취급된다. 핵심부는 매개 
파일들을 서로 붙일수 있는 가장 기본적인 후크 ( hook ) (우에서 언급된 VFS ) 만을 제공하며 중 
간조종구조의 생성과 관리 를 통하여 실제적기능성(핵 심부와 응용프로그람에)을 제공한다. 
이 추상화준위는 모든 파일조종이 사용자공간파일체 계조종코드보다는 오히 려 실증된 조종 
구조객체 에 작용하는 핵 심부체 계 호출로서 실현될수 있게 하는 기 본열쇠 이 다. 

여 기서 사용자공간파일체 계조종코드는 파일을 열기 위하여 조종구조로 하여 금 체 계 
규모와 처 리기 각각을 차례로 배정 혹은 해제할수 있게 한다. 응용프로그람은 파일을 어 
떤 입출력매체형태 대표적으로 SISC 디스크와 같은 기억장치 등에 기억된 바이트들의 선 
형적인 배렬을 주소화하기 위한 추상화된 형태로 리용한다. 

파일 에 접 근하기 위하여 OS 는 매 개 파일자료에 대 하여 열기，닫기, 읽 기, 쓰기 를 위 
한 파일 관리대 면부를 제 공한다. 

완충기，캐쉬 및 기억기쪼각수집 

완충기 는 완충기 억 된 파일의 내 용을 의 미하는것 이 아니 라 물리 적디 스크에 완충기 억 된 



그림 3-3. VFS 의 기 본구조 
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내용을 표현한다. 반대로 캐쉬는 실제적으로 파일의 내용을 고속으로 기억한다. 

Linux 에 서 완충기 와 고속완충기 의 동작은 가상기 억기 ( VM ) 의 기 능과 성 능에 크게 의 
존한다. 가상기 억기는 어떤 조작체 계 에서나 가장 복잡한 구성 요소중의 하나이며 그 구체 
적 내 용에 대 해서 는 여 기서 깊 이 취 급하지 않는다. Linux 2.4 의 가상기 억 기 에 대 한 구체 적 
내용은 2000년 6월 McGraw-Hill 에서 출판된 《Linux internal 》 을 참조할수 있다. 

그림 3-3 은 VFS 의 기본구조를 보여 준다. 

그림은 핵 심부가 주기 억 으로부터 어떻 게 완충기를 배정하며 캐쉬를 어 떻게 관리하는 
가를 보여 준다. 


완충기의 캐쉬 

파일 체 계 가 사용자프로그람에 의하여 올려태 우기 되 면 자료블로크를 읽 고 쓰기 위하 
여 블로크장치 에 대 한 많은 요청 을 생 성한다. 모든 블로크자료의 읽 기 쓰기요청 은 표준핵 
심 부루린 ( routine ) 호출에 의 하여 buffer_head 의 형태로 장치 구동기에 주어 진 다. 여기에는 
블로크장치구동기 가 요구하는 모든 정 보가 주어 져 있 다. 장치식 별 자는 장치 를 유일 적으 
로 식별하며 블로크번호는 어느 블로크를 읽어야 하는가를 구동기에 알려 준다. 

모든 블로크장치 들은 갈은 크기 를 가진 블로크들의 선형모임 으로 볼수 있다. 물 
리적블로크장치에 대한 접근속도를 높이기 위하여 Linux 는 블로크화된 캐쉬를 리용 
한다. 체계에서 모든 블로크화된 캐쉬들은 새로운 완충기나 이미 리용된 완충기에 관 
계없이 이 캐쉬의 어 데 인가에 보존된다. 이 캐쉬는 모든 물리적블로크장치들에 공유 
되는데 어느 한 시각에 캐쉬에는 여러개의 블로크완충기가 있게 된다. 이 완충기들은 
체계의 블로크장치들중의 어느 하나에 속하며 흔히 여러가지 상태에 있게 된다. 만일 
캐쉬로부터 유효한 자료를 제공 받을수 있으면 체계는 물리적장치에 대한 접근을 기 
억하게 된다. 

블로크장치로부터 자료를 읽거나 혹은 거기에 자료를 쓰는데 리용되는 블로크완충기 
는 캐 쉬 로 들어 간다. 일정한 시 간이 초과되 면 완충기 는 보다 새 로운 봉사를 기 다리 는 완 
충기를 위하여 캐쉬 로부터 제 거될수도 있고 혹은 자주 접근되는 완충기 라면 캐쉬 에 그냥 
남겨 둘수도 있다. 캐쉬안에 있는 블로크화된 완충기들은 자기의 블로크식별자와 완충기 
의 블로크번호에 의하여 유일 하게 식 별된 다. 

캐쉬는 2개의 기능부분으로 구성된다. 

하나는 블로크화된 자유완충기 (free block buffer ) 의 목록인데 지원되는 완충기크기에 
해 당하는 한개 목록이 존재하며 체 계의 블로크화된 완충기 들은 이 목록에 대 하여 먼저 
생성된것이 먼저 제거되는 대기렬로 된다. 현재 지원되는 완충기크기는 512, 1024, 2048, 
4096, 8192 byte 들이다. 

다른 하나는 캐쉬 그자체 이 다. 이 부분은 꼭갈은 하쉬첨수를 가지 는 완충기사슬에 
대 한 지 적 자들의 백 토르로 구성 되 는 하쉬표이 다. 

하쉬 첨 수는 자체 의 장치 식 별 자와 자료블로크의 블로크번 호로부터 생 성 된다. 

그림 3-4 는 몇개 입 구점 을 가진 하쉬 표를 보여 준다. 블로크화된 완충기 들은 자유목록중 
의 어느 하나에 있든가 혹은 캐쉬에 있게 된다. 블로크화된 완충기들이 캐쉬에 있을 
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그림 3-4. 캐쉬 


때도 역시 가장 최근에 사용된 목록 ( LRU ) 에서 대기렬을 형성한다. 

매개 완충기형 에는 하나의 LRU 가 존재하며 이것들은 체계 가 어느 한 형의 완충기들 
에 대 하여 작업 을 진행하는데 러 용된다. 

례를 들어 새 자료를 디스크의 비여 있는 완충기에 써넣는 경우를 들수 있다. 

완충기 의 형 은 그것 의 상태 를 반영하는데 현재 Linux 는 다음의 형 들을 지 원 한다. 


clean 

사용되지 않은 새 완충기 

locked 

기록을 기다리면서 잠그어 져 있는 완충기 

dirty 

새톱고 유효한 자료를 포함하며 기록될수는 있으나 
아직까지 쓰기문서가 정해 지지 않았다. 

shared 

공유된 완충기 

Unshared 

한번 공유되 였으나 현재는 공유되지 않은 완충기 
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파일체계가 완충기의 읽기를 요구 할 때마다 그 기초를 이루는 물리적장치들은 캐쉬 
로부터 블로크를 선택하려고 한다. 만일 캐쉬로부터 완충기를 선택할수 없으면 적합한 
크기의 자유목록으로부터 지워 진 완충기를 선택하며 이 새 완충기가 캐쉬로 가게 된다. 
만일 요구 한 완충기가 캐쉬에 있으면 그 완충기는 새롭게 갱신된것일수도 있고 갱신되지 
않은것일수도 있다. 

갱신되지 않은것이거나 새 블로크화된 완충기라면 파일체계는 장치구동기에 디스크 
로부터 적 합한 자료블로크를 읽 어 들일것을 요구해 야 한다. 

모든 캐쉬들과 마찬가지로 캐쉬는 그것이 효과적으로 동작하며 캐쉬를 리용하 
는 블로크장치들사이 에 캐쉬 입구점들을 정 교하게 배정 할수 있도륵 유지관리되 여 야 
한다. 

Linux 는 캐 쉬 에 대 하여 많은 상세한 관리 적작업 을 수행할수 있도록 bdflush 핵 심 부데 
몬 ( daemon ) 을 리 용하는데 캐 쉬 가 리 용되 고 있는것 으로 하여 어 떤 일들이 자동적 으로 수 
행되는것도 있다. 


bdflush 핵심부데몬 

bdflush 핵심부 ( daemon ) 데몬은 체계가 변경된 완충기를 너무 많이 가지고 있을 때 즉 
어떤 시각에 디스크에 자료가 완전히 다 씌여 진 완충기를 많이 가지고 있을 때 거기에 
대 한 동적응답을 제 공하는 간단한 핵 심 부데몬이다. 

이 데몬은 체 계 기동시 작시 에 핵 심 부스레 드 (kernel thread ) 로서 출발한다. 혼돈을 피 하 
기 위하여 이것을 “ kflushd ” 라고 부르는데 이 데몬은 체계의 프로쎄스를 보아야 할 때 
리용하는 ps 명령을 씨서 볼수 있다. 대체로 이 데몬은 체계안에서 변경된 완충기의 수가 
많아 질 때까지 기다리면서 대기 ( sleep ) 상태에 있게 된다. 완충기들이 배정되거나 제거될 
때마다 체계안의 변경된 완충기들의 수가 검사된다. 체계안의 전체 완충기수의 퍼센트가 
커 지 면 bdflush 가 대 기 상태 에 서 벗 어 난다. 보통 기 정값 (default threshold ) 은 60%이 지 만 체 
계가 완충기를 비우고 싶은 경우에는 bdflush 가 어느 때나 기동할수 있다. 이 값은 관측 
할수도 있으며 update 명령으로 변경시킬수도 있다. 


# update_d 
bdflush version 1.4 

0 : 60 변경된 블로크를 검사하기 위한 LRU 목록의 최대비 

1 : 500 bdflush 가 능동화될 때마다 써 넣기 위한 변경된 블로크의 최대개수 

2 : 64 refill_freelist 에 의 하여 자유목록에 적재될 새 완충기들의 개수 

3 : 256 refill_freelist 로 bdflush 를 능동화하기 위 한 변경된 블로크규정 값 

4 : 15 자유클라스터 ( cluster ) 를 주사하기 위한 캐쉬의 퍼 센트값 

5 : 3000 flush 하기전까지 자료완충기 가 낡아 지 는 시 간 

6 : 500 flush 하기 전까지 비 자료 ( dir . bitmap . 등)완충기 가 낡아 지 는 시 간 

7 : 1884 캐쉬적재의 평균상수 

8 : 2 LAV 비(완충기제거 를 위한 턱값결정 에 리용) 
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모든 변경된 완충기들은 자료가 기록되여 낡아 질 때마다 BUF_DIRTY LRU 목록과 
련결되며 또한 bdflush 는 자기가 가지고 있는 디스크의 외부에 적당한 수의 완충기를 써 
넣 으려고 한다. 이 값은 update 명 령 에 의하여 관측될 수도 있으며 조종할수도 있는데 기 정 
값 ( default ) 은 500이다. 매개의 파일체계가 서로 관련되여 있는 한 캐쉬와 완충기의 배정은 
아주 단순하다. 

파일체계는 캐쉬로부터 페지캐쉬나 새로운 완충기를 위한 새 폐지를 요구하 
며 캐쉬는 핵심부의 자유페지목록이 이 요구를 만족시키도록 해당한 페지들을 
제 거 한다. 

만일 이와 갈은 조작을 계속하면 결국 모든 기억에 대해서도 적용되는 결과가 초래 
될것 이 다. 이것을 피 하기 위하여 Linux 의 설계 자들은 분리기 술 즉 다음과 같은 2중재생 
방법을 제안하였다. 

첫 째 만일 핵 심 부프로쎄 스가 자유폐 지 를 요청할 때 요청 이 절 박하지 않으면(즉 조종 
용의 긴급한 중단이 없으면) 기 억배정 자에 대 한 호출이 기 억을 재생시키 기 위한 기능을 
얻 기 위하여 기 억 재 생 기 능을 차례 로 호출한다. 

둘째 만일 기 억 배 정호출이 발생하지 않으면 우선 순위 가 낮은 데 몬인 kswapd 가 정 
규적 으로 자유 기 억 상태 를 검 열 하고 더 낮은 경 우에 는 기 억 재 생 을 시 작한다. 

매 경우에 기억재생기능은 동일하다. 핵심부는 파일을 가상기억，폐지，캐쉬에 대응 
시키는 과정을 처 리 하는 페지표를 포함하는 여 러 가지 자료구조를 거 치면서 순환한다. 핵 
심부는 해 당 페지 를 통과한 마지 막시각부터 접근되지 않은 페지 를 찾고 만일 그 페지를 
찾으면 리용하지 않고 자유목록에 그것 을 돌려 보낸 다. 

Kswapd 

kswapd 는 폐지들을 주기적으로 순환하면서 유연한 동작을 보장할수 있도록 하는데 
충분한 자유페지를 확보하게 한다. 

/ proc / sysMn/kswapd 에 는 3개 의 파라메 터 들이 있 다. 


/ proc / sys / vm / $ cat kswapd 
512 32 32 

첫 번째 파라메 터 는 tries_base 이 다. 이 파라메 터 는 kswapd 가 매 통과마다 비 우려 고 하 
는 4〜8개 로 분할된 페 지수이다. 여 기서 보다 큰 파라메터 는 전체 적 인 폐지교환 ( swap ) 성 능 
을 제고할수 있도록 교환페지공간을 더 빨리 해제시킨다. 

두번째 파라메터는 tries_min 인데 kswapd 가 매 통과에서 비워 야 할 페지의 최소개수 
를 나타낸다. 

세번째 파라메터는 kswapd 가 매 통과에서 써 넣은 폐지의 수이 다. 값이 크면 kswapd 
가 한개 I/O 에서 더 많은 페지를 가지게 될수 있으며 따라서 성능이 제고된다. 그러나 
지 나치게 값이 크면 매우 큰 I/O 조작이 발생하여 정상동작이 페쇄될수 있다. 
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과일체계객체 


Linux VFS 는 블로크장치우에서 자료를 기 억，접 근，관리 하기 위 한 객 체 ( object ) 들의 
모임과 호상작용한다. 이러한 객체들은 다음과 같다. 

▼ 파일 ( file ). 파일은 자료를 읽거나 혹은 쓸수 있고 또한 기억에 넘겨 질수도 있으 
며 때로는 파일이름목록을 파일로부터 읽을수도 있다. 파일은 UNIX 가 가지고 있 
는 파일서술자 (file descriptor ) 개념에 아주 밀접히 대응한다. Linux 에서 파일은 
struct , file-operation 에 기 억된 몇 개의 방식 을 가진 struct , file 에 의 하여 서 술된다. 

• 색 인마디 ( Inodes ). 색 인마디 는 파일 체 계 안에 있는 기 본객 체 를 말한다. 색 인마디 는 
정규파일일수도 있고 등록부일수도 있으며 기호적련결이나 어떤 다른 객체일수 
도 있다. VFS 는 서로 다른 객체들사이에 뚜렷한 차이는 두지 않지만 실제적으로 
파일체 계를 실현하는데 적 당한 성 질을 부여하여 보다 높은 준위의 핵 심부가 서 
로 다른 객체를 취급할수 있게 일정한 차이를 두도록 한다. 매 개의 색 인마디는 
struct . Inode_operation 에 기 억되여 있는 여 러가지 방식을 가지는 struct inode 에 의 
하여 표현된다. 파일과 색 인마디는 거의 근사하지 만 일정한 차이를 가진다. 

우선 색 인마디가 가지 고 있는 어떤 내용들이 파일에는 전혀 없는것 이 다. 이 에 대 
한 좋은 실례 는 기 호적련결이 다. 반대 로 색 인마디 를 가지지 않는 파일도 있는데 
특히 pipe(pipe 는 이 름은 아니 지 만)와 소케 트 (unix 의 구역 소케 트는 아니 다.)를 들수 
있다. 또한 파일은 색인마디가 가지고 있지 않는 상태정보도 가지고 있다. 여기 
서는 특히 position 을 들수 있는데 이것은 파일에서 다음것의 읽기나 쓰기를 진행 
해 야 할 위 치를 지적한다. 

• 파일체계 (File System ). 파일체계는 뿌리 ( root ) 라고 하는 한개의 특징적 인 색 인마디 
를 가지는 색 인마디들의 집합이다. 다른 색 인마디들은 뿌리로부터 출발하여 접근 
할수도 있으며 파일 이 름을 조사하여 접 근할수도 있 다. 파일 체 계 는 체 계안에 있는 
모든 색 인마디들에 대하여 평등하게 적용하는 여 러가지 특성을 가지고 있다. 이 
특성 들중에 서 어 떤것 은 READ_ONLY flag 와 같은 기 발이다. 또 다른 중요한 특성 
의 하나는 blocksize 이 다. 매 개 파일 체 계 는 struct super_block 에 의 하여 표현되 며 
이것은 struct super-operations 에 기억된 몇가지조작을 가지고 있다. Linux 에는 상 
위 블로크와 장치번호사이 에 강한 상관관계 가 존재한다. 매 개 파일 체 계 는 파일체 
계 가 존재하는 유일한 장치 를 가져 야 한다. 어 떤 파일 체 계 (nfs 나 proc ) 는 실제 장 
치 에 필 요 없는것 처 럼 만들어 진것 도 있다. 이 때 이 름이 밝혀 지 지 않은 장치 
major 에 대 하여 번호 0이 자동적으로 붙여 진다. Linux 에서 매 파일체계의 형은 
smictfile _ system_type 에 의 하여 표현된다. 이것은 곧 한가지 조작 즉 read_super 를 
포함하는데 이것은 super_block 가 주어 진 파일체계를 표현한다는것을 실증해 준다. 

▲ 이 름 ( name ). 파일체 계 안의 모든 색 인마디 는 이 름에 의 하여 접 근된다. 일 련의 파 
일체 계들에서 는 이름 대 색인 마디 검색 처리가 값 눅게 실현되기 때문 에 
LinuxVFS 층은 현재 능동상태의 캐쉬와 가장 최근에 리용된 이름을 보존한다. 
이러한 캐쉬가 바로 디캐쉬 ( dcache ) 이다. 디캐쉬는 기억내에 나무형태로 만들어 
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진다. 나무안에서 매개 마디는 주어 진 이름을 가지는 등록부안의 색 인마디에 
대응한다. 나무에서 색인마디는 한개이상의 마디와 관련될수 있다. 디캐쉬는 파 
일나무의 완전한 복사가 아니며 해당 나무의 고유한 접두사이다. 이것은 파일 
나무의 임의의 마디 가 캐쉬 안에 있으면 그 매듭의 매 상위도 역시 그 캐쉬안에 
있다는것 을 의 미한다. 나무에서 매 개 마디 는 stract . dentry_operations 에 기 억된 
여러 개의 방식을 가지는 struct dentry 에 의 하여 서술된다. 덴트리 (dentry : d 입구 
점 )들은 파일 과 색 인마디사이 에 서 중간요소로서 작용한다. 매 개 파일은 열 려 
져 있는 덴트리를 지적하며 매 개 덴트리는 그것 이 참조하는 색 인마디를 지적한 
다. 이것은 매개 열려 진 파일에 대하여 그 파일의 덴트리와 그우의 모든 상위 
들이 캐 쉬 에 기 억 된다는것 을 암시해 준다. 

다음절에서는 이 객체들의 구체적인 내용과 Linux VFS 가 이 객체들과 어떻게 호상 
작용하는가에 대하여 고찰한다. 


과 일 


파일구조는 linux / fs.h 에서 다음과 같이 정의된다. 


struct fown_struct 
int pid ; 
uid_t uid, euid; 
int signum ; 

} ； 

struct file { 


/* SIGIO 가 전송되 여 야 할 pid 혹은 -pgrp */ 
/* 소유자를 설 정하는 프로쎄 스의 uid/euid */ 
/* 10에 넘겨 질 posix.lb rt 신호 */ 




struct dentry 



atomic_t 
unsigned int 
mode_t 
loff_t 

unsigned long f_reada, 
struct fown_struct 
unsigned int 
int 


*f_op; 
f_count; 
f_flags; 
f_mode; 
f_pos; 

f_ramax, f_raend, f_ralen, f_rawin; 
f_owner; 
f_uid, f_gid; 
f_error; 


unsigned long 


"need for tty driver,and maybe others*/ 


void 


*private_data; 


}； 
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마당들의 의미는 다음절에서 설명한다. 


f_list 

이 마당은 파일을 여러개 목록들중에서 어느 하나와 서로 련결한다. 매개 능동파 
일체 계 에 는 상위블로크안의 s _ files 지 적자로 시 작되 는 한개 의 목록이 존재한다. 또한 
매 개 자유나무구조 ( fs / file _ table . c 의 free _ list ) 에 대 해서도 하나가 존재 한다. 그리 고 
pipe 와 같은 ( fs / file _ table . c 의 anon _ list ) 이름이 밝혀 지지 않은 파일에 대해서도 하나 
가 존재한다. 

f_dentry 

이 마당은 주어 진 파일에 대한 색인마디를 지적하는 디캐쉬입구점을 기록한다. 만 
일 색 인마디 가 정규파일체 계 에서는 존재하지 않는 pipe 와 같은 객체 를 참조하면 덴트리 
는 d _ alloc _ root 로 생 성 된 뿌리 덴트리 이 다. 


f_op 

이 마당은 해 당 파일 에 서 리용해 야 할 조작방식 을 지 적한다. 


f_count 

해당 파일에 대한 참조회수이다. 매개의 서로 다른 사용자프로쎄스파일서술자에 대 
하여 한개가 존재하며 매 내부리용에 대해서는 +1인 값을 가진다. 


f_flags 

이 마당은 읽기/쓰기，비블로크화，전용추가와 갈은 접근형식을 주어 진 파일에 대하 
여 기 발로 기 억 한다. 이 것 들은 해 당 구성 방식 포함파일 asm / fcntl . n 에 서 정 의 한다. 이 기 발 
들중의 일부는 열기시 간에 만 관계되 며 f _ flags 에 기 억되지 않는다. 이 제 외된 기 발들은 
0_ CREAT , 0_ EXCL , 0_ N 0 CTTY ，0 _TRUNC 이 다. 

이 목록은 fs / open . c 의 flip _ open 에 있다. 

f_mode 

F _ flags 의 아래 쪽에 있 는 두개 의 비 트들은 개 별 적 인 읽 기 나 쓰기 접 근정 보를 이 끌어 
내기 어려운경우에 읽기나 쓰기접근을 부호화한다. 

f_pos 

f_pos 는 현행파일의 위치를 기록하며 그 위치는 파일이 0_ APPEND 기발을 가지지 
않을 때 다음읽기요청과 다음쓰기요청에 리용된다. 

f_reada, f_remax, f_raend, f_ralen, f_rawin 

이 5 개 의 마당은 파일상에 서 순차적접 근패 런을 계 속 추적하는데 리용되 며 앞으로 
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얼마나 읽어야 하는가를 결정한다. 

앞방향읽기에 대해서 분리부분이 있을수도 있다. 

f_owner 

이 구조체는 프로쎄스 id 와 새롭게 리 용되는 자료와 같은 파일에 어떤 사건이 생길 
때 프로쎄스에 전송할 신호를 기억한다. 

현재 건 반，마이 크，직 렬 포구 그리 고 망소케 트들各 이 특성 ( kill_fasync 을 통하여 )을 
리용하는 파일 로 볼수 있 다. 

f-uid, f_gid 

이 마당들은 소유자에 대한 설정과 파일을 연 프로쎄스그롭에 대한 설정을 엄는다. 

이 설정은 전혀 사용되지 않는것처럼 보인다. 

f_error 

f_error 는 NFS 클라이 언트파일 체 계 가 쓰기 오유를 귀 환시 키 기 위 하여 리 용하는 마당이 다. 

fs/nfs 八 vrite.c 에서 설정되여 fs / nfs / file.c 에서 검사되며 mm / filemap . c : gemeric _ file_write 에서 
리용된 다. 

f_versiob 

이 마당은 기본파일체계가 캐쉬상태를 지원하며 무효해 진 캐쉬를 검사하는데 리용 
되는 마당이 다. 

파일은 f_pos 값을 변화시킬 때마다 같이 변경된다. 

실례 로 ext 인 파일체 계 는 이 마당을 등록부가 언제 변경 되 였는가를 검 출하기 위하여 
색 인마디 안의 i_version 마당과 접 속시 키 는데 리 용한다. 

private_data 

이 마당은 매 열 린 파일당 파일정보를 기 억시 키기 위하여 (coda 에서 신임 장과 같은) 
많은 장치구동기들이 리용하는 마당이며 지어는 일부 파일체계들에서도 리용한다. 

과일함수 

파일함수목록은 linux / fs.h 에 다음과 같이 정의되여 있다. 

typedef int(*filldir_t)(void*, const char*, int, off_t, int_t); 

struct file_operations { 

loff_t(*llseek)(struct file*, loff_t, int) ; 

ssize_t(*read) (struct file*, char*,size_t, loff_t*) ; 

int(*readdir) (struct file*, void*,filldir_t) ; 
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unsigned int(*poll)(struct file*,struct poll_table_struct 女 ); 
int(*ioct1)(struct inode*, struct file*, unsigned int, 
insigned long) 

int(*mmap)(struct file*, struct vm_area_struct*); 
int(*open)(struct inode*, struct file*); 
int(*flush)(struct file*); 

int(^release)(struct inode*, struct file*); 
int(*fsync)(struct file*, struct dentry); 
int(*fasync)(int, struct file 〜 int); 
int(*check_media_change)(kdev_t dev); 
int(^revalidate)(kdev_t dev); 

int(*lock)(struct file 〜 int, struct file_lock*); 

}； 

llseek 

이 함수는 seek 체 계 호출을 실현한다. 만일 정의되지 않으면 fs / read _ write.c 로부터 
default_llseek 가 대 신 리 용된 다. 이 함수는 기 대하였 던것 처 럼 f_pos 를 갱 신하며 f_read 마당 
파 f_version 마당을 변화시 킨다. 


read 

read 는 read 체계호출과 실행 가능한것들의 적재 나 분배파일의 읽 기와 같은 다른 경우 
의 파일 읽 기 를 지 원 하는데 리 용된 다. 이 기 능은 pread 나 pwrite 체 계 호출을 제 외 하고는 보 
통 file 구조체마당의 f_pos 에 대 한 지적 자의 편위값 ( offset )( 마지막인수)을 갱 신한다. 블로크 
장치 우의 체 계 파일 용으로 mm / filemap.c 에 있는 generic _ file_read 루린 이 있 다. 이 루린은 색 
인마디 가 readpage 로 정 의된 조작을 가지 고 있다면 이 조작에 리 용할수 있다. 

write 

이 조작은 write 체 계호출을 사용할 때 와 같이 파일 에 자료를 기 록하는 조작이 다. 이 
조작은 자료가 주어 진 장치에 도달했다는것을 필수적으로 담보하지는 못하지만 파일형 
의 의미에 따라 편리할 때 쓸수 있게 대기렬로 준비시킬수도 있다. 

블로크장치 의 파일 체 계 에 대 하여 이 조작을 실 현하기 위하여 generic _ file_write 를 
fs / buffer.c 로부터 block _ write _ partial_page 와 결 합하여 리용할수도 있 다. 

readdir 

readdir 는 등록부라고 가정 할수 있는 파일 로부터 등록부입 구점 을 읽 고 filldirj 역 호출 
( caUback ) 함수를 리 용하여 귀 환시 키 는 기 능을 수행 한다. 이 함수는 이 름에 대 한 지 적 자， 
이름의 길 이，이름을 찾는 파일안에서의 위 치 그리 고 이름과 관련된 색 인마디번호와 함 
께 넘겨 진 void * 호출자를 얻는다. 


38 







만일 filldir 역 호출이 령 이 아닌 값을 귀 환하면 readdir 는 충분하다고 가정 하고 역 시 
귀 환한다. Readdir 가 파일의 끝에 도달하면 0 값을 가지 고 귀 환한다. 달리 말하면 readdir 는 
어 떤 입 구점 들이 filldir 에 주어 진후에야 곧 귀 환한다는것 을 말한다. 이 경 우에 는 령 아닌 
값이 귀환되여야 한다. 오유가 있는 경우에는 부의 값이 귀환된다. 


poll 

poll 은 select 와 poll 체 계 호출을 실 현 하는데 리 용한다. 이 경 우에 poll_table_entry 를 그 
것 이 넘 겨 지 는 poll_table_ struct 에 추가하여 야 한다. 


ioctl 

ioctl 은 ad hoc ioctl 기능을 실현한다. 만일 ioctl 요청 이 알려 진 요청 (FIBMAP, 
FIGETBSZ, FIONREAD) 모임 중의 하나가 아니 라면 그 요청 은 토대 파일 실현에 넘 겨 
진 다. 


mmap 

이 루린은 기억에 대한 파일의 넘기기를 실현한다. 이 기능은 흔히 generic_file_mmap 
를 리용하여 실현한다. 이 과제는 마치 넘기 기 가 허 용된다는것을 립증하여 적 당한 객체 
를 지 적 하기 위한 vm_area_struct 의 vm_ops 마당을 설 정하려 는것 처 럼 보인 다. 

open 

이 조작은 새로운 파일 이 색 인마디 에서 열려 진 때 에 호출된다. 조작은 필요할 때 
열기에 관한 설정을 진행할수 있다. 하지만 이 조작은 많은 파일체계에서는 사용하지 못 
한다. 열기시 에 국부적 으로 파일을 취 하는 례외처 리 로서 coda 가 있다. 


flush 

flush 는 파일서술자가 닫길 때 호출된다. 이 파일에서 열리는 파일서술자도 있을 
수 있으므로 반드시 최 종적 인 파일닫기 는 아닐 수 있 으며 중간열 기 로 된다. 현재 이 
조작을 정의하고 있는 파일체계는 NFS 클라이언트 (client) 만이며 이 NFS 는 확정되지 않 
은 임의의 쓰기후 요청 을 폐지한다. flush 는 close 체계호출을 통하여 오유상태를 반 
대로 귀환시킬수 있으며 따라서 검사해 야 할 오유가 있으면 그것의 사용을 요구할수 
있 다. 

유감스럽게도 flush 가 소거를 위한 마지막호출인지 아닌지를 현실적으로 결정할 수단 
은 없다. 


release 

release 는 파일 우에서 마지막핸들 (handle) 이 닫길 때 호출된 다. 이 조작은 필요한 임의 
의 특별한 해제 작업 을 수행 할수 있다. release 는 어 떤것 에 대 해서 는 오유상태를 귀 환시키 
지 못하며 따라서 현실에서는 int 형보다 void 형이여야 한다. 
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fsync 

이 조작은 fsync 나 fdatasync 체 계 호출을 수행 한다(이 것 들은 식 별 가능하다.). 이 조 
작은 파일 에 대 한 모든 미확정쓰기 가 성 과적 으로 장치 에 도달할 때 까지 귀 환될 수 없 
다 . fsync 는 generic_buffer_fdatasync 를 리 용하여 부분적으로 실현할수도 있는데 이 
generic_buffer_fdata 는 넘 겨 진 색 인마디 의 모든 페 지 우의 변경 된 완충기 들에 쓰기 를 
완료한다. 

fasync 

이 조작은 파일의 FIOASYNC 기 발이 변경될 때 호출된다. int 파라메터 는 기 발에 새 로 
운 값을 설 정한다. 현재 이 방법 을 쓰는 파일 체 계 는 없 다. 

check_media_change 

이 방법은 기본매체가 변화되였는지 안되였는지를 검사하는 조작이다. 만일 변화되 
였다면 참값을 귀환시 킨다. 파일체계 가 올려 태우기 하려고 할 때 호출된 디스크구동기의 
바깥부분만은 read_super 에 있게 된다. 만일 이 점에서 참인 값을 귀환하면 장치와 관련된 
모든 완충기들은 정 확하게 확증되지 않는다. 


revalidate 

revalidate 는 check_media_change 에서 서술 한바와 같이 매체가 변경 되여 완충기들이 
무효화된 후에 호출된 다. 그러므로 check_media_change 가 정의 되여야만 의미를 가지게 된 
다. 이 조작을 그것과 완전히 구별되는 조작인 inode:revalidate 와 혼돈하지 말아야 한다. 


lock 

이 조작은 POSIX 의 잠금을 여 유조종할수 있게 파일봉사를 하는 함수이 다. 이 함수 
는 FLOCK 형 식 의 잠금에 는 리용하지 않는다. 이 조작은 파일 체 계 에 의하여 자기 에 게 고 
유한 특정의 수법으로 서로 다른 잠금방법이 실현되는 망파일체계에서는 특별히 쓸모가 
있다. 잠금을 설정하거나 해제할 때 먼저 이 방법으로 실현하며 다음 표준 POSIX 잠금코 
드를 리용한다. 이 방법 으로 잠금을 실 현 할수 있 으나 국부코드가 실 패하면 잠금을 해 제 
할수 없게 된다. 

한 프로쎄 스에 어 떤 잠금이 설정되 여 있는가 즉 이 조작에 의하여 귀 환된 정 보들을 
알아 보려고 할 때 국부잠금은 검사되지 않는다. 

색 인 마디 

색 인마디 는 임 의의 UNIX 파일체 계 의 기 본구성블로크이다. 그러므로 이 중요한 구 
조에 대 한 아주 명백한 관점을 가지는것은 특별히 중요하다. 색 인마디는 그자체 가 다 
른 객 체 즉 파일 이 나 등록부를 표현할수 있다. 매 개 파일 에 는 색 인 마디 가 있 으며 파 
일 은 그것 이 존재하는 파일 체 계 와 파일체 계 상의 색 인 마디번 호에 의하여 유일하게 식 
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별된다. 매개 색인마디는 여러가지 조작 혹은 함수에 대한 지적자를 포함한다. 이러한 
조작들은 자료의 읽기나 쓰기，파일안에서 변위의 탐색，새로운 파일을 만들거나 이미 
있는 파일의 이름바꾸기 등을 수행할수 있다. 모든 연산이나 조작들은 색인마디우에 
서 무효하다. 실례로 사용자는 정규적인 파일우에서 이름을 재정의할수 있다. 왜냐하 
면 UNIX 에서 이름의 재정의는 상위등록부에서의 조작이며 파일 그자체에서의 조작은 
아니 기때 문이 다. 한편 파일뿐 아니 라 파이 프 ( pipe ) 에 관해 서 도 찾을수 없 다. 매 개 색 인 
마디는 그것이 포함하는 자료블로크수에 대한 계수값을 포함한다. 실제적인 자료블로 
크의 수는 배정된 자료블로크와 간접블로크의 합이다. 명 령 fsck 는 실제 적 자료블로크 
수를 계 산하고 그것 을 색 인마디 가 제 시하는 실제 적블로크수와 비 교한다. 만일 색 인마 
디 가 부정 확한 값을 포함하고 있으면 fsck 는 그 값을 맞추기 위하여 연산자를 제시한 
다. 매개 색 인마디는 64 bit 크기의 마당을 가전다. 이 크기는 색 인마디와 관련되는 파일 
안의 자료바이 트수이 다. 크기마당의 정 확성 은 크기마당으로부터 색 인마디 와 관련된 블 
로크들의 최 대 값을 계산하고 색 인마디 가 주는 실제 적블로크수와 대 비하여 기 대 되는 
블로크계 수값을 비 교하는 방법 으로 대 략적 으로 검 사된다. 

매개 색 인마디는 다음의 정보를 포함한다. 

▼ 마디 가 있는 장치 

• 파일 방식 

• 파일형 

• 잠금정 보 

• 파일길이(파일에서 바이트길이) 

• 련결계수값(파일에 대한 련결수) 

• 소유자의 사용자와 그룹 ID 

• 접근특권준위 

• 마지 막파일 접 근시 간 

• 색인마디의 마지막변경시간 

▲ 디스크상의 파일블로크주소(파일자료를 포함하는 내용에 대 한 지적 자) 

Linux 는 능동상태 의 캐 쉬 와 가장 최 근에 리용한 색 인마디 를 보존한다. 이 색 인마디 
에 접 근하는데는 두가지 경 로가 있 다. 

첫번째 는 디 캐쉬 를 통한 방법 이 다. 디 캐 쉬 에서 매 개 덴트리 는 색 인마디 로 간주되며 
따라서 캐쉬 에 그 색 인마디들이 보존된다. 

두번째 경 로는 색 인마디하쉬표를 리용하는 방법 이 다. 

매 개 색 인마디 는 파일체 계 상위 블로크의 주소와 색 인마디 번호에 기 초하여 8 bit 하쉬 표 
로 만들어 져 있다. 갈은 하쉬값을 가지는 색인마디들은 2중련결목록으로 서로 사슬화된 
다. 하쉬표를 통한 접 근은 iget 함수를 리 용하여 실현되 는데 iget 함수는 색 인마디 를 찾을수 
있는 파일체계와 nfsd 에 의하여서만 호출된다. 색인마디는 디캐쉬에서 찾을수 없다. 색인 
마디 상에 서 하쉬법 의 기 초는 매 개 파일 체 계 가 파일 을 32 bit 로 유일 적 으로 식 별 할수 있 다 
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는 가정으로 어느 정도 제한하고 있는데 있다. 

NFS 파일체 계 에서 는 최 소한 이것 이 문제 이 다. 여 기서는 하쉬 에서의 유일한 식 별자로 
256 bit 파일 핸들을 리 용하고 있 다. nfsd 는 파일 핸들-색 인마디 넘 기 기 함수를 제 공하는 파일 체 
계를 가지고 있으므로 보다 편리하다. 이때 넘기기함수는 파일핸들을 가장 정교한 방법 
으로 해석해 야 한다. 

시동시 에 핵 심부는 핵 심 부객체 들을 위한 캐 쉬 에 기 억된 코드를 생 성하는 루린(핵 심 
부기억배정코드)을 호출하여 파일의 접 근성 에 대 한 일 반적정 보를 보관하는 표를 초기 화 
한다. 핵 심 부는 파일 이 열릴 때 까지 파일조종구조인 첫번째 객체를 실제 적 으로 생성하지 
못한다. 이미 언급한 캐쉬에 기억된 특수한 핵심부객체를 바로 색인마디라고 부른다. 색 
인마디는 핵 심부안에 있으면서 파일체계，망경 로조종기 혹은 다른 기 억관리체 계 에 의하 
여 관리되는 특별한 객체이다. Linux 에서는 보통 C 언어로 색인마디를 실현하는데 설계자 
체 는 매 우 추상화되 고 객체지향화되 여 있다. 

아래 의 코드는 색 인마디핵 심 부구조체 이다. 

struct inode { 

struct list_head 
struct list_head 
struct list_head 
unsigned long 
unsigned int 
kdev_t 
umode_t 
nlink_t 
uid_t 
gid_t 
kdev_t 
off_t 
t ime_t 
t ime_t 
t ime_t 

unsigned long 
unsigned long 
unsigned long 
unsigned long 
struct semaphore 
struct inode_operations 
struct super—block 
wait_queue_head_t 
struct file_lock 
struct vm_area_struct 


i_hash; 

i_list; 



i_uid; 

i_gid; 

i_rdev; 

i_size; 

i_at ime 

i_mt ime 

i_ctime 



*i_op; 

*i_sb; 

i_wait; 



*i_mmap; 
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struct page 



struct dquot 
struct pipe_inode_info 
unsigned long 
unsigned int 
unsigned char 
atomic_t 


*i_pages; 
i_shared_lock; 
*i_dquot[MAXQUOTAS] 


*i_pipe; 

i_state; 



i_sock; 
i_writecount; 


unsigned int 
_u32 
union { 


i_generation; 



}； 

이 구조체 에서 가장 중요한 마당들에 대 하여 보기로 한다. 


i_hash 

i _ hash 련결목록은 같은 하쉬바게 트에 하쉬화한 모든 색 인마디 들을 서 로 련결 한다. 
하쉬 값은 상위 블로크의 주소와 색 인마디 의 번호에 기 초한다. 이 하쉬 값은 특정한 마디 의 
람색속도를 비 약적으로 높인다. 


i-list 

i _ list 련결목록은 여러가지 상태에 있는 색인마디를 련결한다. 여기에는 주어 진 파일 
체계의 모든 변경된 색인마디들을 보존하는 superblock -> s _ dirty , 사용되지 않는 색인마디 
들을 목록화한 inode _ imu Se d ， 능동사용중에 있는 변경되지 않는 색 인마디들을 목록화한 
inode _ in _ use 들이 포함된다. 


i_dentry 

i _ dentry 련결 목록은 색 인마디 로 간주되는 모든 struct dentry 들의 목록이 다. 이것들은 
덴트리의 d _ alias 마당과 서로 련결된다. 


i_version 

i _ version 마당은 변경 된 레 코드 ( record ) 를 리 용하기 위 하여 파일체 계 를 사용한다. 대 표 
적 으로 i _ version 은 사건대 역변수의 현행값으로 설정되며 그후에 증가된다. 때때 로 파일체 
계코드는 련 관된 파일 구조체 의 f _ version 에 대 한 i _ version 의 현 행값을 지 정한다. 파일 구조 
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체를 계속 사용하는 경우에 색 인마디의 값의 변동에 대하여 알려 줄수 있으며 필요하면 
파일구조체의 캐쉬에 기억된 자료를 소거할수도 있다. 


i_nrpages 

이 마당은 i_pages 와 련결된 페지의 수를 기록하는데 이때 이 값은 색인마디에 캐쉬 
에 기 억되 고 add_page_to_inode_queue 에 의 하여 추가되며 remove_page_ from_ inode_queue 
에 의하여 감소된 다. 


i_sem 

이 쎄 마포 (semaphore) 는 색 인마디 에 변화가 있는가를 감시 한다. 색 인마디 에 대 하여 
비 원자적접 근을 시 도하는 임 의의 코드(대 기상태 에 있는 두개의 련관된 접 근)는 먼저 이 
쎄마포를 요구해 야 한다. 여 기 에는 블로크의 배정 및 비배정，여 러 가지 방향에 대 한 탐색 
과 갈은 내용들이 포함된다. 


i_flock 

i_flock 는 색 인마디 에 잠금을 요구하는 struct file_lock 구조체 의 목록을 지 적 한다. 


i_mmap 

색 인 마 디 의 넘 기 기 를 서 술 하 는 모 든 vm_area_struct 구 조 체 는 vm_next_share 와 
vm_pprev_share 지 적 자를 서 로 련결 하며 이 i_mmap 지 적 자는 목록안의 요소를 지 적 한다. 

Lpages 

이 마당은 색인마디를 참조하는 페지에서의 캐쉬안의 모든 페지들의 목록이다. 이것 
들은 이 기 억기 안의 next 와 prev 련결상에서 서로 련결된다. 

i_shared_lock 

이 회 전 잠금 (spin lock) 은 i_mmap 목록의 vm_next_share 와 vm_prev _share 지 적 자를 감 
시 한다. 

i_state 

3 개 의 가능한 색 인마디 상태비 트가 있 다. I_DIRTY, I_LOCK, I_FREEING 

I_DIRTY 변경 된 색 인마디 는 매 상위 블로크 s_dirty 목록에 있 으며 동기 가 요청 된 
다음순간에 기록된다. 

I_LOCK 색인마디들이 생성될 때나 읽기，쓰기하는동안 잠금이 진행된다. 
I_FREEING 참조계수값과 련결계수값이 둘다 령이 될 때 색인마디가 가지는 상태 
이 다. 이 상태 는 fat 파일체 계 에서 호출되 는 igrab 의 리 용과 같다. fat 는 
색 인마디로 흥미 있는 작업을 할수 있다. 
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Lflags 

i_flags 마당은 상위블로크의 s _ flag S 마당에 대응한다. 많은 기발들은 체계범위에서나 
혹은 색 인마디 마다 설정 될수 있 다. 


MS—NOSUID 

MS—NODEV 

MS—NOEXEC 

MS_SYNCHRONOUS 

MS_MANDLOCK 

S_QUOTA 

S—APPEND 

S_IMMUTABLE 

MS—NOATIME 

MS _ ODD_RENAME 


setuid / setgid 는 이 파일 에 서 허 용되 지 않는다. 

색 인마디 가 장치 전용파일 이라면 열 수 없 다. 

이 파일 을 실 행할수 없 다. 

모든 쓰기 가 동기 되 여 야 한다. 

강제잠금이 수행 된 다. 

Quotas (배 정 몫)이 초기 화된 다. 

파일을 덧붙이기만 할수 있다. 

뿌리에 의하여서도 파일이 변경되지 않는다. 

이 파일이 접근될 때 색 인마디상에서 접근시간을 갱신하면 
안된다. 

NFS 에 관계된다. 


i_writecount 

이 마당이 정수이면 쓰기접근을 요구하는 클라이언트(파일이나 기억배치도)의 수를 
계 수한다. 부수이 면 이 수의 절 대 값이 현재 VM _ DENYWRITE 넘 기 기 의 수를 계 수한다. 
한편 0이면 쓰거나 혹은 쓰기로부터 다른것을 정지시키는 일이 없다. 



이 마당은 전혀 사용되지 않으며 오직 ATTR _ FLAG _ SYNCRONOUS , ATTR _ FLAG _ 
APPEND , ATTR _ FLAG _ IMMUTABLE , ATTR _ FLAG_NOATIME 의 조 합 으 로 되 는 
ext 2_ real _ inode 에 의 하여서 만 설정된다. 


Lgeneration 

i _ generation 의 목적 은 지 우기/재 리 용의 전후에 색 인마디 사이 를 구별 할수 있게 하는 
것 이 다. 

NFS 에서는 이것이 아주 중요하다. 현재 ext 2 와 nfsd 에서만 이 마당을 보존한다. 이 
마당의 리용을 그렇게 정의 하였다고 하여 이것을 VFS 계층에 도입할수 있다는것은 아니 
다. 오히 려 매 개 파일 체 계 는 주어 진 색 인마디 에 대 하여 유일한 파일 행 들을 제 공할 기 회 
가 있어야 하며 그래야 매개는 가장 좋은 유일성을 담보할수 있다. 

색인마디에 작용하는 함수 

다른 객체와 마찬가지로 색인마디는 그것들우에서의 표준함수들의 모임에 의하여 조 
종된다(조작이 라고도 한다.). 

색 인마디의 조작구조체는 다음과 같다. 
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struct inode_operations{ 

struct file_operations*default_file_ops; 
int(^create)(struct inode*, struct dentry*,int); 
struct dentry*(*lookup)(struct inode*,struct dentry*); 
int(*link)(struct dentry*, struct inode*,struct dentry*); 
int(*unlink)(struct inode*, struct dentry*); 
int(*symlink)(struct inode*, struct dentry*, const char*); 
int(*mkdir)(struct inode*, struct dentry*, int); 
int(*rmdir)(struct inode*, struct dentry*); 
int(*mknod)(struct inode*, struct dentry*, int, int); 
int(*rename)(struct inode *, struct dentry*, struct inode*, 
struct dentry” ; 

int(*readlink) (struct dentry*, char*, int) ; 

struct dentry*(*follow_link)(struct dentry *, struct dentry *, 
unsigned int); 

int (*get_b1ock) ( struct inodelong,struct buffer_head*, 
int) ; 

int(*readpage)(struct file*, struct page*); 

int(*writepage)(struct file*, struct page*); 

int(*flushpage)(struct inode 〜 struct page 〜 unsigned long); 

void(^truncate)(struct inode*); 

int(^permission) (struct inode*, int) ; 

int(*smap)(struct inode*, int); 

int(^revalidate)(struct dentry*); 


default_file_ops 

이 마당은 색인마디에서 열린 파일에 대한 기정의 조작표를 지적한다. 

파일 이 열 릴 때 파일구조체 안의 f _ op 마당은 이 표로부터 초기 화되 며 다음 
file _ operation 표의 open 조작이 호출된 다. 이 조작은 f _ op 를 다른(비 기정 표) 조작표로 바꾸 
도록 선 택할수 있 다. 

실례 로 장치전용파일을 열 때 이 조작을 수행할수 있다. 

Create 

이것과 함께 다음에 보게 될 8개의 조작들은 등록부색 인마디 에서만 의미를 가진다. 

Create 는 VFS 가 주어 진 등록부안에서 주어 진 이름으로 파일을 만들려고 할 때 호 
출된 다. VFS 와 이 름이 존재하지 않는다는것 을 검 사하면 넘 겨 진 덴트리 는 색 인마디 지적 
자가 NULL 이 라는것 을 의 미하는 부의 덴트리 로 된다. 만일 성 공하면 create 는 
get _ empty _ inode 로 캐 쉬 로부터 새 로운 자유색 인마디 를 생 성 하며 마당을 채 워 넣 고 그것 을 
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insert_inode_hash 를 리 용하여 하쉬 표에 삽입 한다. 다음 mark_inode_dirty 를 리 용하여 하쉬 
표에 삽입 한다. 다음 mark_inode_dirty 를 리 용하여 그것 이 변경 된것 이 라는 표식 을 달고 
d_instantiate 에 의 하여 디 케 쉬 에 서 술한다. 

int 변수는 파일 의 방식 (mode) 을 표현 하는데 이 를 리 용하여 방식 이 S_IFREG 라는것 을 
지 적하며 요구되 는 허 용비 트를 정 의한다. 


lookup 

lookup 는 이 름이 (덴트리 에 의 하여 주어 진) 등록부 (inode 에 의 하여 주어 진)안에 존재 
하는가를 찾아 보며 있는 경 우에 d_add 를 리용하여 덴트리 를 갱 신한다. 이 과정 은 색 인 
마디의 찾기와 적재를 포함한다. 

만일 찾다가 실패하면 색 인마디 지적 자값이 NULL 인 부의 덴트리 를 귀 환시켜 이 내 
용을 알려 준다. 또한 오유나 NULL 을 귀환시킬뿐아니라 덴트리를 귀환시킬수도 있는데 
이 경우에 넘겨 진 덴트리는 해제된다. 이러한 가능성이 실제적으로 리용되는가는 아직 
불투명 하다. 

link 

link 조작은 첫번째 덴트리 에 의하여 참조된 이 름으로부터 두번째 덴트리 에 의하여 
참조된 이름까지의 공고한 련결을 실현한다. 이때 두번째 덴트리는 색인마디에 의하여 
참조되는 등록부안에 있다. 

만일 성공하면 새로운 덴트리(부의 덴트리였던)에 련결파일의 색 인마디를 접수하기 
위 하여 d_instentiate 를 호출한다. 


unlink 

unlink 는 색 인마디 가 참조하는 등록부로부터 덴트리 에 의하여 참조된 이 름을 삭제한 
다. 성공하면 d_delete 가 호출된다. 


symlink 

이 마당은 주어 진 값을 가지는 주어 진 이름으로 주어 진 등록부에 기호이름을 생 
성한다. 성 공하면 덴트리 에 새 색 인마디 를 련결 하기 위하여 d_instantiate 를 호출한다. 


mkdir 

주어 진 상위，이름，방식을 가지는 등록부를 생성한다. 


rmdir 

이 름으로 지적된 등록부(비 여 있는 경 우)를 지우며 덴트리 d_delet e 로 소거한다. 


mknod 

주어 진 상위，이름，방식 그리고 장치번호를 가진 장치전용파일을 생성한다. 다음 
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덴트리 에 새 색 인마디련결 d_ins 切 ntiate 을 호출한다. 


rename 

첫 색 인마디 와 입 구점 이 등록부와 현재 존재하는 이 름을 참조한다. rename 은 두번째 
색 인마디와 덴트리 에 의하여 주어 진 이름과 상위를 가지도록 객체의 이름을 재정의한다. 
새로운 상위가 변경된 이름의 하위가 아니 라는것을 포함하여 모든 일반적검사가 완료된다. 


readlink 

덴트리에 의하여 참조되는 기호적련결을 읽어 낼수 있으며 이때 값은 int 로 주어 진 
최대길이로 사용자완충기 ( copy _ to _ user ) 에 복사된다. 

follow_link 

어떤 등록부(첫번째 덴트리)와 다른 등록부(두번째 덴트리)안에 이름이 있으면 등록부로 
부터 이름을 동반하는 명백한 결과는 두번째 덴트리에서 찾을수 있다. 

만일 색인마디가 어떤 다른 불투명한 객체를 요구하면 결과는 기호적련결에서와 마 
찬가지 로 적 당한 새 로운 덴트리 를 귀 환시 키 도록 follow_link 를 제 공한다. int 인수는 namei 
검색 에 대 한 부분에서 설명한 lookup 기 발의 수를 포함한다. 

get_block 

이 조작은 지정된 파일의 블로크를 보관하는 장치블로크를 찾는데 리용된다. inode 와 
long 은 관측되 고 있는 파일과 블로크수(블로크수는 파일체 계의 블로크크기 에 의하여 분 
할된 파일 변위 이 다.)를 지 적한다. get_block 는 buffer_head 의 b_dev 와 b_blocknr 마당을 초기 
화하며 때 로 b_state 기 발로 변경 시 킨다. int 인수가 령 이 아닐 때 새 블로크가 존재 하지 않 
으면 새 블로크가 배정된다. 


readpage 

readpage 는 mm / filemap.c 에 의해서만 호출된다. 


호출 방식 


▼ generic _ file_readahead 와 filemap_nopage 로부터 try _ to _ read_ahead 

• do _ generic _ file_read 

• sys_sendfile 

• filemap_nopage 

▲ generic_filemap 는 null 이 아닐것을 요구 

따라서 이 조작은 sendfile 체 계 호출을 리 용하기 위 하여 서 나 혹은 generic _ read_file 을 
file:read 조작에 리용하려고 할 때 파일의 기억에로의(기대했던것처럼) 넘기기에 필요하다. 
readpage 는 폐 지 안에 서 실 제 적 인 읽 기 를 기 대 하지 못한다. 폐 지 는 읽 기 를 위 하여 반드 
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시 배렬되여야 한다. 클라이언트들은 자료를 리용하기전에 페지가 잠금해제되기를 기 
다린다. 

readpage 는 fs / buffer.c 에 정 의된 block _ read _ full_page 를 리용하여 실현할수 있 다. 이 루 
린은 inode : get_block 가 정의 되 여 있고 문제의 블로크에 접 근하기 위 하여 buffer_heads 를 
설정 한다고 가정 한다. buffer_heads 는 “ end _ buffer _ io _ sys ” 를 호출하기 위 하여 완성 의 목적 
으로 설정되며 페지상의 모든 완충기들이 완료될 때 폐지의 잠금을 해제한다. 


writepage 

writepage 는 linux / mm / filemap.c 로부터 호줄된 다. 또한 filemap _ write _ page , filemap _ 
swapout , filemap _ sync_pte 그리 고 gurenic 一 file_mmap 로부터 do _ write_page 에 의 하여서도 호 
출된다. Writepage 는 fs / buffer.c 로부터 block _ write _ full_page 를 리용하여 실행될수 있다. 
block _ write _ full_page 는 block _ read_fullpage 와 가까운 쌍둥이 이 다. 

이것들의 중요한 차이점은 다음과 같다. 

▼ block _ read_fullpage 는 ll _ rw_block 로서 읽기를 시작하며 한편 block _ write_fullpage 
는 완충기들만을 설정 하고 쓰기는 시 작하지 않는다. 

• block _ read_fUllpage 는 령 으로 설정된 생성 기 발들을 가지 고 inode : get_block 를 호출하 
며 한편 block _ write_fullpage 는 그것 을 1로 설 정한다. 

▲ block _ read_fullpage 는 완료목적으로 호출된 end _ buffer _ io_async 를 얻기 위 하여 
init_buffer 를 호출한다. 

이 두개 의 루린들은 류사성 과 차이 점 을 더 잘 정 의할수 있도록 비 트를 지 울수도 있 다. 


flushpage 

flushpage 는 mm / filemap.c 와 mm / swap _ state.c 로부터 호줄된다. 

mm / filemap.c 는 페 지 가 해 제 되 기 전 에 페 지 상에 서 확정 되 지 않은 I/O 가 없 다는것 을 확 
인 하기 위 하여 tmncate _ inode_page 에 의 하여 호출된 다. 

파 일 체 계 

우리가 사용하는 파일체계라는 용어에 일정한 애매성이 있다는것을 고려하면서 이 
부분에 대하여 학습하기로 한다. 

파일 체계라는 말은 ext 2, nfs 혹은 coda 와 같은 파일체계의 특정 한 형이나 부류를 의 
미 하는데 리 용될 수도 있 고 / user , /home 이 나 혹은 / dev / hda 4 파일 체 계 등과 같은 파일 체 계 
의 특별한 실례를 의미하는데도 리용될수 있다. 

첫번째 경 우는 파일체 계의 등록을 의미하며 두번째 경우는 파일체 계의 올려태 우기를 
의 미 한다. 

그런데 현재 많은 사람들이 이러한 애매한 용어를 계속 사용하고 있다. Linux 는 
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register_filesystem 를 호 출 하 여 새 로 운 파 일 체 계 형 에 대 하 여 알 아 본 다 ( 부 분 체 계 
unregister _ filesystem 을 호출하는 방법으로 파일체계형을 알지 않고 할수도 있다.). 

형식적쓰임은 다음과 같다. 


♦include <linux/fs.h> 

int register_filesystem(struct file_system_type*fs); 
int unregister_filesystem(struct file_system_type *fs) ; 


함수 register_file system 은 성 공하는 경 우 0 을 귀 환하며 fs = NULL 이 면 EINVAL 
을 귀환한다. 또한 fs ᅳ NEXT !=NULL 혹은 이미 같은 이 름으로 파일체 계 가 등록되 여 있 
으면 EBUSY 를 귀환시킨다. 

이 함수는 또한 모듈로서 적재되 고 있는 파일체 계 를 위하여 init _ module 로부터 혹은 
fs / filesystems . c 의 filesystem _ setup 으로부터 (직접적으로 혹은 간접적으로)도 호출된다. 함수 
unregister _ filesystem 은 오직 모듈의 cleanup _ module 루린으로부터만 호출된 다. 

이 함수는 성공하는 경우 0을 귀환하며 인수가 등록된 파일체계에 대한 지적자가 아 
니면 EINVAL 을 귀환시킨다(특히 unregister _ filesystem ( NULL ) 은 Oops 일수 있다.). 

파일 체 계 등록과 비 등록실 례 는 fs / ext 2/ super . c 에 서 볼수 있 다. 


static struct file_system_type ext2_fs_type={ 

“ext2” , 

FS_REQUIRES_DEV/*|FS_IBASKET */,/*ibaskets have unresolved 
bugs */ ext2_read_super, 

NULL 

}； 

int_init init_ext2_fs (void) 

{ 

return register_filesystem(&ext2_fs_type); 

} 

# ifdef MODULE 
EXPORT_NO_SYMBOLS ； 
int init_module(void) 

{ 

return init_ext2_fs (); 

} 

void cleanup—module(void) 

{ 


unregister_filesystem(&ext2_fs_type); 





structfile _ system_type 는 linuxfs.h 에서 정의되며 다음의 형식을 취한다. 

struct ysteitl^ype { 

const char*name; 
int Jf 멓 ‘ 를 Lags; 

struct super_b1ock* (*read_super) ( struct super_block*, 
void*, int) ; 

struct file_system_type*next; 


name 

이름마당은 단순히 ext 2, iso 9660 혹은 msdos 와 같은 파일체계형에 대한 이름을 준다. 
이 마당은 열쇠로 사용되며 이미 사용중에 있는 이름으로 파일체계를 등록할수 없다. 이 
름마당은 또한 현재 핵심부에 등록된 모든 파일체계형을 목록화한 / proc/filesystems 파일에 
리 용될수도 있 다. 파일 체 계 가 모둘로서 실 현될 때 이 름은 모둘의 주소공간을 지 적하는데 
이 주소공간 (vmallocd 구역 으로 넘 기 기 한)은 사용자가 만일 cleanup_module 의 unregister _ 
filesystem 으로 등록을 루락시키 려고 한다거 나 또 cat / proc / filesystems / 을 실행 하려 고 하면 
참조되지 않는 이름 즉 개 발의 첫 단계 에서 파일체 계서술자들에 의하여 형성된 공통오유 
에 대하여 Oops 를 참조하게 될것이다. 

fs_flags 

파일 체 계 의 특성 을 기 록하는 ad hoc 기 발의 수이 다. 파일 체 계 기 발 fs_flags 에 대 하여 
몇 가지 설 명 하기 위하여 가능한 기 발들을 소개한다. 


FS _ REQUIRES_DEV 


FS _ NO_DCACHE 


FS—IBASKET 


우에 서 언급한대 로 올려태 우기 된 매 파일 체 계 는 어 떤 장치 혹 
은 어떤 장치 번호와 련결된 다. 만일 파일 체계의 형이 
FS _ REQUIRES_DEV 이 면 실지 장치 는 파일체 계 가 올려태 우기 
될 때 주어 져야 하며 그렇지 않는 경우 이름이 밝혀 지지 않 
은 장치가 배정된다. nfs 와 procfs 는 장치를 요구하지 않는 파 
일체계 에 대 한 실례이 며 ext 2 와 msdos 는 요구하는 실례 이 다. 

이 기 발은 선언은 하지 만 전혀 리용되 지 않는다. fs.h 의 해 설 
문으로부터 알수 있는바와 같이 기본취지는 디캐쉬가 오직 실 
제적으로 사용중에 있는 파일에 대한 입구점만을 보존하게끔 
파일 체 계 를 표식 화하는것 이 다. 

FS _ NO_DCACHE 와 같이 이 기 발은 전혀 사용되지 않는다. 그 취 
지는 디캐쉬가 사용중에 있거나 사용된 입구점들을 가지지만 그 
밖에는 그 어떤것도 캐쉬에 기억되지 않는다는것이다. 

다른 vapor 기발 : 이 기발은 ibasket 에 대하여 취급한 부분을 보기 
바란 다. 
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next 

next 는 모든 file _ system_type 를 서 로 사슬모양으로 련결시 키 기 위한 지 적 자이 다. 이 
지 적 자는 NULL 로 초기 화되 여 야 한다 ( register_filesystem 은 이 지 적 자를 설 정 하지 않으며 
NULL 은 next 가 설정되지 않으면 -EBUSY 를 귀환시킨다.). 

read_super 

read_super 조작은 파일체 계(개 체 )가 올려태 우기될 때 호출된 다. struct super_block 는 
s _ dev _ 나 s_flag 마당을 제외 하고는 지워 진다(모든 마당이 0). 

void * 지 적 자는 mount 체 계 호출로부터 아래 로 넘 겨 지 는 자료에 대 하여 지 적 한다. 꼬 
리의 int 마당은 read_super 가 오유에 대해서 통보하겠는지 안하겠는지를 통보한다. 이 마 
당은 root 파일체계를 올려태우기할 때에만 설정된다. Root 가 올려태우기될 때 가능한 매 
파일체 계 가 성 공될 때 까지 차례 로 실행된다. 이 경 우에 인쇄오유는 말끔히 제거 되 지 못 
할수도 있다. 


이 ■ 훅은 텐트리 

VFS 층은 파일 의 모든 경 로이 름을 관리하며 토대파일 체 계 가 그것 들을 인식 하기 
전에 디캐쉬입구점들로 변환한다. 이때 기호련결의 과제만은 례외되며 이 과제는 토 
대파일체계로 그대로 넘겨 진다. 그러면 토대파일체계가 그것을 해석한다. 이경우 
모둘의 경계가 약간 모호해 지는 감이 있을수 있다. 디캐쉬는 많은 struct dentry 들로 
구성 된 다. 매 덴트리 는 파일체 계안의 한개 파일 이 름성 분과 그 이 름(이 름이 하나면) 
과 관련된 객체 에 대 응한다. 매 개 덴트리 는 dcache.dentry 에 존재 해 야 하며 파일체 계 
올려태우기관계를 기 록해 야 하는 그것의 상위를 참조한다. 디캐쉬는 색 인마디캐쉬의 
기 본요소이 다. 디 캐 쉬 입 구점 이 존재 하면 색 인마디 도 역 시 색 인마디 캐 쉬 에 존재 한다. 
반대로 색인마디캐쉬에 색인마디가 있을 때 색인마디는 그 캐쉬에 있는 덴트리를 
참조한다. 

덴트리구조체 

덴트리 구조체 는 linux / dcache.h 에 서 정 의 한다. 


strut qstr { 

const unsigned char * name; 
unsigned int len; 
unsigned int hash; 

}； 

# define DNAME_INLINE_LEN 16 
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struct dentry { 


int d_count; 
unsigned int d_flags; 
struct inode * d_inode; 


struct dentry * d_parent; 
struct dentry * d_mounts; 
struct dentry * d_covers; 
struct list_head d_hash; 
struct list_head d_lru ; 


/* where the name belongs to - NULL 
s negative* / 

/* parent directory*/ 

/* mount information*/ 


/* lookup hash list*/ 

/* d_count = 0 LRU list*/ 


struct list_head d_child; /* child of parent list */ 
struct list_head d_subdirs; /* our children*/ 
struct list_head d_alias; /* inode alias list*/ 

struct qstr d_name; 

unsigned long d_time; /* used by d_revalidate */ 

struct dentry_operations *d_op; 

struct super_block d_sb; /* The root of the dentry tree*/ 


unsigned long d_reftime; /* last time referenced*/ 


void* d_fsdata; /* fs-specific data*/ 

unsigned char d_i name[DNAME_INLINE_LEN]; /*small names*/ 


}； 


d_count 

이 조작은 단순한 참조계수조작이다. 이 계수는 d_subdirs 목록을 통한 상위로부터의 
참조는 포함하지 않지 만 하위 로부터 d_parent 참조는 포함한다. 이것 은 캐쉬의 잎마디 만이 
0인 d_count 값을 가질 수 있 다는것 을 암시해 준다. 이 입 구점 들은 볼수 있 으므로 d_ku 에 
의하여 서 로 련결된다. 

d_flags 

현재 정의된 파일체계를 실현하여 사용가능한 두개의 기발이 있는데 여기에서는 서 
술하지 않는다. 

이 기 발로는 DCACHE _ AUTOFS _ PENmNG 과 DCACHE _ NFSFS _ RENAMED 을 들수 
勢다. 


d_inode 

해 당 이름과 관련된 색 인마디 에 대 한 지적 자이 다. 이 마당은 NULL 일수 있는데 이름 
이 존재하지 않는다는것 을 암시하는 부의 입 구점 을 가리킨 다. 
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d_parent 

이 마당은 상위덴트리에 대한 지적자이다. 파일체계의 뿌리나 혹은 파일에서처럼 닉 
명의 입구점 에 관하여 이 지적 자는 포함되는 덴트리 자체를 거꾸로 지적 한다. 


d_mounts 

올려태우기된 파일체 계 를 가지 는 등록부에 대 하여 d _ mount 는 그 파일체 계의 뿌리덴 
트리 를 지적한다. 다른 덴트리 에 대 해서는 그자체 덴트리 를 거꾸로 지적한다. 올려태우기 
점에서 파일체계를 올려 태우기 할수 없으며 따라서 하나이 상의 긴 d_mount 입구점 사슬은 
존재할수 없 다. 


d_covers 

이 마당은 d _ m 0 imt 와 반대내 용을 표현한다. 올려태 우기 된 파일 체 계 의 뿌리 에 대 하여 
이 마당은 올려태우기된 등록부의 덴트리를 지적한다. 다른 덴트리 에 대 해서 는 덴트리 자 
체 를 지 적 한다. 


d_hash 

2중련결목록으로서 한개 하쉬바케트안의 입구점들을 서로 사슬로 결합한다. 


d_lru 

이 마당은 캐쉬 에서 참조되 지 않은 잎마디 들의 2중련결목록을 제 공한다. 목록의 머 
리부는 dentry _ unused 의 대 역 변수이 다. 이 변수는 LRU(Least Recently Used : 가장 최 근에 
사용)에 차례 로 기 억된다. 핵심부의 다른 부분들이 디캐쉬안의 사용되지 않은 입구점들 
을 잠금할수 있는 기억 이 나 색 인마디를 개정할것을 요구하면 그것들은 d _ ku 에서 제거가 
능한 입 구점 들을 찾고 그것 을 prune_dcachei 의 하여 제 거 할수 있게 준비 해 주는 
select _ dcache 를 호출할수 있다. 


d_child 

이 목록머 리 부는 해 당 덴트리 의 d _ parent 의 모든 하위 들을 서 로 련결 하는데 리 용된 
다. 이에 관해서는 d _ sibling 이 보다 더 좋은 이름이 라고 생각해도 좋다. 

d_subdirs 

이 덴트리 의 모든 하위 들을 련결하는 d _ child 의 머 리부이다. 물론 요소들은 파일 로 
간주해도 좋으며 부분등록부로는 간주하지 않는다. 그러므로 d _ child 가 더 좋은 이름으로 
되며 또 이미 사용되고 있다. 


d_alias 

파일들은(어떤 다른 파일체계의 객체들) 다중고정련결을 통하여 파일체계안에서 다 
중이름들을 가질수도 있기때문에 다중덴트리도 갈은 색인마디들을 참조할수 있다. 이런 
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현상이 생길 때 덴트리는 d_alias 마당에 련결된다. 색인마디의 i_dentry 마당은 이 목록의 
머리부로 된다. 


d_name 

d_name 마당은 마당의 하쉬 값과 함께 입 구점 의 이 름을 포함한다. 이 름부분마당은 덴 
트리의 d_iname 마당을 지 적할수 있으며 만약 마당이 충분히 길지 않으면 개 별적 으로 배 
정 된 문자렬 을 지 적한다. 


d_time 

이 마당은 토대파일체계에 의 하여서만 리용되는데 그것들이 원하든 원하지 않든지 간 
에 가정적으로 리용될수도 있다. 왜냐하면 이 입구점이 유효성을 다시 검사하여야 한다 
는것 을 강조하는것 이 중요하기 때 문이 다. 

d_op 

d_op 는 해당 덴트리를 어떻게 조종하는가에 대한 정의와 함께 struct dentry_operations 
를 지 적한다. 

d_sb 

이 마당은 객체를 가지고 있는 덴트리에 의하여 참조된 파일체계의 상위블로크를 지 
적 한다. 

d _ inode -> i_sb 를 쓰는것보다도 오히 려 이것 이 필요하겠는가가 명백 치 않다. 


d_reftime 

이 마당은 d_count 가 령 으로 될 때 마다 jiffies 에 현재 시 간을 설정 하지 만 리 용되 지 는 
않는다. 


d_fsdata 

이 마당은 요구될 때 리용할 파일체계를 정의 하는데 쓸수 있다. 이 마당은 현재 파 
일핸들을 기 억 하기 위하여 nfs 에 서 만 리용된 다(필 자는 파일핸들이 색 인마디 에 해 당하고 
이 름에 는 해 당되 지 않는다고 생 각하고 있 었지만 여 러 nfs 봉사자들은 동의하지 않았다.). 


d_iname 

d_iname 은 참조를 쉽 게 하기 위 하여 이 름의 첫 16문자를 기 억 한다. 만약 이 름이 완 
전히 일치되면 d _ name.name 이 여 기를 지적한다. 그렇지 않으면 따로따로 배정된 기 억을 
지 적 한다. 

덴트리함수 

대다수의 덴트리에 대한 조종은 모든 파일체계에서 공통이며 따라서 덴트리상에서 
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수행 하려 고 하는 대 부분의 조작들은 dentry_operation 목록에 조작방식 을 가지 고 있지 않는 
다. 오히려 그것은 몇개의 파일체계를 실현하여 불투명한 방법으로 조종되는 몇가지 조 
작들을 제공한다. 파일체계는 NULL 로서 모든 조작들을 그만두도록 선택할수 있는데 이 
경우에는 기정조작이 적용된다. 

linclude / linux / dcache.h 로부터 구조체정의 를 보면 다음과 같다. 


struct dentry—operations{ 

int(*d_revalidate) (struct dentry *, int) ; 
int(*d_hash)(struct dentry*, struct qstr*); 

int(*d_compare)(struct dentry*, struct qstr*, struct qstr*); 

void(*d_delete)(struct dentry*); 

void(*d_release)(struct dentry*); 

void(*d_iput)(struct dentry*, struct inode*); 

}； 


d_revalidate 

이 조작은 경로찾기가 입구점이 아직 유효한가를 알아 내기 위하여 디캐쉬에 있는 입 
구점을 리용할 때마다 호출된다. 만약 여전히 유효한 경우에는 1을 귀환시키며 그렇지 않 
은 경 우에 는 0을 귀 환시 킨다. 기정값은 귀환값 1로 가정한다. int 인수는 이 검색과 관련이 
있는 기 발을 제 공하며 LOOKUP _ FOLLOW , LOOKUP _ DIRECTORY , LOOKUP _ SLAHOK , 
LOOKUP_CONTINUE 중의 임의의것을 포함한다. 이 것들에 대 해서 는 namei 에 관한 절에서 
서 술한다. 

이 조작은 공유파일체 계 에서처 럼 VFS 층이 어 떤 작업 을 진행하지 않아도 파일체 계 가 
변경될수 있을 때만 필요하다. 만약 d_revalidate 가 0을 귀환하면 VFS 층은 디캐쉬로부터 
덴트리를 정리하여 간결하게 만든다. 이 작업은 능동상태에서 사용되지 않는 임의의 하위 
덴트리 를 제 거 하는 d_invalidate 에 의 하여 수행 되 며 만일 성 공되 면 덴트리 를 하쉬 상태 에 서 
해 제 한다. 


d_hash 

만약 파일체계가 유효한 이름이나 혹은 이름과 등가인것들에 대하여 비표준적 인 규 
칙을 가지고 있다면 이 루린은 유효성을 검사하여 정규하쉬를 귀환시키는 기능을 제공해 
야 한다. 

만약 이름이 유효하면 하쉬 가 계산되며 (모든 등가적이름들에 대 해서도 같아야 한 
다.) 그것 을 qstr 인수에 기 억한다. 이 름이 무효하면 적 당한(부의) 오유코드가 귀 환되 여 야 
한다. 

덴트리인수는 덴트리 의 이 름이 아직 완성 되 지 않았으므로 상위이 름의 덴트리 ( q 的•에 
서 찾은)로 된다. 
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d_compare 

이 마당은 두개 의 qstr 에 대 하여 그것 들이 서 로 같은가를 알아 보기 위하여 비 교한다. 
두 qstr 가 같은 때 만 0을 귀 환한다. 순서는 중요치 않다. 


d_delete 

이 마당은 덴트리가 dentry_unused 목록에 옮겨 지기전에 참조계수값이 0에 도달할 때 
호출된 다. 


d_release 

이 마당은 덴트리 가 최 종적 으로 해 방되 기 직 전에 호출되 며 d_fsdata 을 해 제하는데 리 
용된 다. 


d_iput 

이 마당은 덴트리 가 제거될 때 색 인마디를 개 방시키 기 위하여 iput 대 신 호출된다. 이 
조작은 iput 와 등가인 조작들과 그밖의 요구하는 다른 조작들에서 도 쓸수 있다. 

Unux 상우 I 블로크 

올려 태 우기 된 매 개 파일체 계 는 super_block 구조체 에 의 하여 서 술된 다. 파일 체 계 가 올 
려 태우기된다는 사실은 linux / mount.h 에서 볼수 있는 선포문인 struct vfsmount 에 기 억된다 
는것을 말한다. 


struct vfsmount 


kdev_t mmt_dev; 
char* mnt_devname; 



unsigned int mnt_flags; 
struct super_block mnt_sb; 
struct quota_mount_options mnt_dquot; 
struct vfsmount*mnt_next; 


/* 적용되는 장치*/ 

/* ■장치이 름 즉 /dev/dsk/hdal*/ 
/* 올려태우기된 등록부이름*/ 

/* 이 장치의 이름*/ 

/* 상위블로크에 대 한 지적 자*/ 

/* 디스크 배정정의 올려태우기선택*/ 
/* 련결목록의 다음요소지적 자*/ 


이 vfsmount 구조체들은 fs / super.c 의 vfsmn 仕 ist 로부터 출발하는 단순련결목록과 서로 
련결된다. 이 목록은 장치 특히 디스크배정코드에 주어 진 올려태우기된 파일체계정보를 
찾는데 중요하게 리용된다. 

vfsmount 가 상위 블로크목록과 분리 되 여 있 어 야 하는 리 유는 상위 블로크가 이 미 존재 
하면 read_super 파일 체 계 정 의 조작대 신 fs / super . c : get _ super () 가 fs / super . c : read _ super () 를 만족 
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시 키 기 때문이 다 . 

한편 년농 11^11 납의 입구점은 파일체계가 올려태우기되지 않으면 곧 련결을 차단한다 . 

매개 올려태우기는 역시 후에 설명하게 될 디캐쉬에 기록되며 이것은 경로이름을 측 
정 할 때 리용하는 올려태우기정보의 원천으로 된다 . 

상우 I 블로크구조체 

상위 블로크구조체에 대하여 간단히 서술한다 . 

struct super—block { 
struct list_head 
kdev_t 

unsigned long 
unsigned char 
unsigned char 
unsigned char 
struct file_system_type 
struct super_operations 
struct dquot_operations 
unsigned long 
unsigned long 
struct dentry 
wait_queue_head_t 
struct inode 
short int 
short int 
struct list_head 
struct list_head 
union { 

/* 배치구성된 파일이 여기서 입구점을 엄는다 .*/ 

void *generic_sbp; 

} u; 

/* 다음의 마당은 VFS 만이 필요 */ 

struct semaphore s_vfs_rename_sem; /^Kludge*/ 


s_list; /* 첫번째로 유지 */ 
s_de v; 

s_blocksize; 

s_blocksize_bits; 

s_lock; 

s_dirt; 

*s_type; 

*s_op; 
dq_op; 
s_flags; 



s_ibasket_count; 

s_ibasket_max; 

s_dirty; /* 변경된 색인마디 * 


우의 삭제된 부분을 가진 union u 의 모든 파일체계정의요소들을 포함하는 완전한 선 
포문을 보려면 linux/fs.h 를 참조할것 
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s_list 

올려 태 우기 된 모든 파일 체 계 의 2중련결 목록이 다 ( linux / Hst . h 을 볼것 ). 

s_dev 

해 당 파일체 계 가 올려 태 우기 된 장치(알려 지 지 않은 이 름일수 있 다.) 

s_blocksize 

파일 체 계 의 블로크크기 이 다. 지 금도 리 용되 고 있는지 는 확실 치 않다. 2의 루승으로 
표시되여야 한다. 

s_blocksize_bits 

s _ blocksize 는 2의 루승 즉 log 2( s _ blocksize ) 이 다. 

s_lock 

상위블로크의 현재 잠금상태를 지적한다. 이 마당은 lock _ super 와 anlock _ super , 
lock _ kemel 에 의 하여 관리 된 다. 

s_wait 

상위블로크상에서 s _ lock 잠금을 기다리고 있는 프로쎄스의 대기렬이다. 

s_dirt 

상위블로크가 변화될 때마다 설정되고 또 상위블로크가 장치에 씌여 질 때마다 지워 
지 는 기 발이다. 이 조작은 파일체 계 가 올려태 우기해제될 때 혹은 sync 체 계호출에 대 한 
응답으로 발생한다. 

s_type 

이 마당은 우에서 설명 한 struct file _ system _ type 구조체 에 대 한 단순한 지 적 자이 다. 

s_op 

다음에 설명할 struct super _ operations 에 대 한 지 적 자이 다. 

dq_op 

다음에 설명할 디스크배정조작에 대한 지적자이다. 

s_flags 

매 색 인마디안의 어떤 상태 를 결정 하기 위 한 기 발들과 론리 합을 취 한 기 발들의 목 
륵이 다. 

전체 파일체계에 대해서 적용되는 기발은 하나뿐이며 그것을 여기에서 설명한다. 다 
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른것 들은 색 인마디 에 대 하여 론의 한 조건에 서 설 명 한다. 

MS_RDONLY 기발이 설정된 파일체계는 읽기전용으로만 올려태우기된다. 쓰기는 
허 용되 지 않으며 간접 적 인 변경 도 불가능하다. 례 를 들어 상위블로 
크에서의 올려태우기시 간이 나 파일에서의 접근시 간 등은 변경할수 
없다. 


s_magic 

이 마당은 장치의 자료가 해 당 파일체계에 대응한다는것을 확인하기 위 하여 장치로 
부터 읽어 들이는 식별번호이다. 이 조작은 여러가지 특성을 가진 파일체계들을 서로 구 
별 하기 위하여 Minix 에 서 리 용된것 으로 알려 져 있 다. 

왜 이것 이 구조체의 일반적부분으로 되 여 있었는가 하는 리유는 명 백하지 않으며 그 
것은 파일체계가 요구하는 파일체계정의부분으로 완전히 제한되지 않는다. 이 마당의 유 
용성의 하나는 fs/nfsd/vfs.c:nfsd_lookup() 에 있는데 proc 나 nfs 파일체계가 NFS 를 통해서는 
접 근할수 없 다는것 을 확인 하는데 리용한다. 


s_root 

이 마당은 파일체 계 의 뿌리 로 간주되 는 struct dentry 이 다. 이 마당은 파일체 계 로부터 
뿌리 색 인마디를 적재 하며 그것 을 d_alloc_root 에 넘 겨 주는 방법 으로 표준적 으로 생성된 
다. 이 덴트리는 올려태우기명 령 에 의하여 디캐쉬 에 겹 쳐 이 어 진다 (do_mount 가 d_mount 
를 호출). 

s_ibasket, s_ibasket_count, s_ibasket_max 

이 세가지 마당은 색인마디의 바 스케트 인데 현재 판본에는 이러한것들이 존재하지 
않는다. 


s_dirty 

i_list 마당에 련결된 변경된 색 인마디들의 목록이다. 색 인마디가 mark_inode_dirty 에 의 
하여 변경된 색 인마디로 표식 이 붙으면 이 목록에 놓는다. sync.inode 가 호출되면 이 목 
록안의 임의의 색인마디가 파일체계의 write_inode 조작에 넘겨 진다. 


s_files 

해 당 파일 체 계 상의 열린 파일 들의 목록이 다와 련결 된). 

실례로 이것은 파일체계가 읽기전용으로 재올려태우기되기전에 쓰기용으로 열린 파 
일이 있는가를 검사하는데 리용된다. 

u.generic_sbp 

공용체 U 는 매개 파일체계 에 대하여 콤파일시에 대 략적으로 알려 지는 한개의 파일 
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체 계정 의 용상위 블로크정 보구조체 를 포함한다. 모둘로서 적재 되 는 임 의의 파일체 계 는 개 
별적 구조체 를 배정 해 야 하며 u . generic _ sbp 에 지 적 자를 배 치 해 야 한다. 

s_vfs_rename_sem 

이 쎄마포는 등록부의 이름을 재정의하는 동안 파일체계범위의 잠금에 리용된다. 이 
조작은 등록부의 이름바꾸기가 그의 하위자체에 대해서는 끝나게 되는 가능한 경쟁조건 
을 감시하는것으로 표현된다. 이 쎄마포는 등록부가 아닌 객체의 이름바꾸기때에는 필요 
하지도 않으며 사용되지도 않는다. 

상우 I 블로크함수 


struct super _ operations 에 정의된 조작은 다음과 같다. 


struct super_operations{ 

void(*read_inode)(struct inode*); 

void(*write_inode)(struct inode*); 

void(*put_inode)(struct inode*); 

void(*delete_inode)(struct inode*); 

int(*notify_change)(struct dentry*, struct iattr*); 

void(*put_super)(struct super_block*); 

void(*write_super)(struct super_block*); 

int(*statfs)(struct super—block*, struct statfs*, int); 

int(*remount_fs)(struct super_block*, int*, char*); 

void(*clear_inode)(struct inode*); 

void(*umount_begin)(struct super_block*); 


이 조작들은 핵심부의 잠금이 유지된 상태에서만 호출된다. 이것은 블로크의 안전을 
보장할수 있다는것 을 의미 하지만 그것들자체 의 병 행접근을 막는다는데 도 의의가 있다. 
모든 조작은 프로쎄 스문맥 으로부터 호출되 며 중단조종자나 bottom half 로부터 는 호출되 지 
않는다. 


read_inode 

이 조작은 올려태우기된 파일체계로부터 정의된 색인마디를 읽기 위하여 호출된 
다. 이 조작은 fs / inode . c 안의 iget 에 서 나온 get _ new _ inode 로부터 만 호출된 다. 이 조작 
에 넘겨 진 struct inode * 인수에서 마당 i _ sb , i _ dev 와 특히 i _ ino 는 색 인마디를 어느 파 
일체계로부터 읽어야 하는가를 지적하기 위하여 초기화된다. 이 조작은 또한 VFS 가 
주어 진 색인마디에서 조작을 요구하는대로 호출할수 있도륵 관련된 struct inode _ 
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operations 마당을 지 적 하기 위 하여 struct inode 의 i_op 마당을 설 정 하여 야 한다(다른것 들 
중에 서 ). 

흔히 iget 는 그 파일 체 계 에 해 당한 색 인마디 들을 읽 기 위하여 특정한 파일 체 계안에 서 
호출된 다. fs / nfsdMsfh.h 에 는 한가지 주목할만한 례 외 가 존재 하는데 그것 은 nfs 파일 핸들의 
정보에 기초한 색 인마디를 엄는데 리용된다. 

이 조작은 그것 을 제 공하는 파일체 계 에 의 하여 서 만(간접 적 으로) 리용될수 있기 때 문 
에 (nfsd 를 제외 하고) 수출될것을 요구하는것은 부당하다. 

이 런 경 우를 피 하는 방법 은 단순 32 bit 색 인마디번호보다도 더 좋은 유연성 을 가지 고 
특정 한 색 인마디 를 식 별 하는것 이 다. 

nfsd 의 리용은 파일 핸들(혹은 그것 의 다른 부분)을 가지 며 색 인마디 를 귀 환시키 는 대 
면부로 갱신할수 있다. 


write_inode 

이 조작은 mark _ inode_dirty 로 변경된것에 표식을 붙인 색인마디들을 호출한다. 조작 
은 파일상에서와 파일체계상에서 sync 요청 이 생길 때 호출된다. 이때 색 인마디에서 임의 
의 정 보가 장치적 으로 안전하다는것 을 확인해 야 한다. 

put_inode 

이 조작은 색인마디상에서 참조계수값이 감소될 때마다 호출된다. 이것을 더 많은 
색인마디들이 사용중에 있거나 또 여러명의 사용자를 가진다는것으로 리해하면 안된다는 
것을 강조한다. 

put_inode 는 i_count 마당이 감소되기전에 호출되며 따라서 put_inode 는 마지막참조인가 
를 확인하려면 i_count 가 1인가 0인가를 검사해야 한다. 

이 조작을 정의하고 있는 거의 모든 파일체계들은 색인마디에 대한 마지막참조가 해 
제될 때 즉 i_count 가 1이거 나 0일 때는 몇 가지 특별한 조종을 진행하는데 리 용한다. 


delete_inode 

deletejnode 가 색 인마디 에 대 한 참조계수값이 령 으로 될 때 마다 호출된다고 정의 하 
면 역시 련결계수값 ( i _ nlink ) 도 령이 라는것을 말해 준다. 파일체계는 이 러한 상태를 파일체 
계의 색 인마디 를 무효화시키거 나 사용된 자원을 해 방시키는 상태 로 처 리 한다고 가정할수 
있다. 이 조작과 앞의 조작은 i_count 마당이 0으로 될 때마다 호출되는 한가지 조작으로 
바물수 있으며 그러면 파일체계는 그것 이 0인 i_nlink 로 어떤 특별한 조작을 할수 있는가 
를 결정할수 있다. 이러한 조작을 현행 파일체계에 의하여 실현시키는데서 유일한 난점은 
ext 2 가 i_count 에 무관계 하게 put_inode 가 호출될 때 ex 任- discard_prealloc 를 호출하는것 이 다. 
그러면 이것이 더이상 가능하겠는가. 과연 실현할수 있겠는가 하는 문제가 제기된다. 

notify_change 

이 조작은 색 인마디 의 속성 이 변할 때 즉 새 로운 속성모임 을 지 적하는 인수 
s 仕 uct_iattr 가 변 할 때 호출된 다. 만일 파일 체 계 가 이 조작을 정 의 하지 않으면 (즉 NULL 
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이 면) VFS 는 POSIX 표준속성검 증을 실 현 하는 fs/iat 仕 . c : inode _ change_ok 루린을 리용한다. 다 
음 VFS 는 색 인마디 에 낡았다는 표식을 단다. 만일 파일체계가 그자체 notify_change 를 수행 
하면 이 조작은 속성을 설정 한 다음 mark _ inode _ dirty ( inode ) 를 호출한다. 이 조작을 어떻게 
실현하는가 하는 실례는 fs / ext 2/ inode . c : ext 2_ notify _ change () 에서 볼수 있다. 

put_super 

이 조작은 vfsmntlist 로부터 입구점들을 제거 하기 전에 umount (2) 의 마지막단계에서 호 
출된 다. 또한 이 조작은 상위블로크잠금이 유지 된 상태 에 서 호출된 다. 전형 적 인 실 현으로 
는 이 올려태우기개체를 위하여 정의된 파일체 계비공개 자원 즉 색 인마디비트매프，블로 
크비 트매 프，상위블로크를 포함하는 블로크머 리 부를 개 방하는것 과 만일 파일 체 계 가 동적 
적 재모둘로서 실현된 다면 계 수값을 유지한 모둘을 감소시키 는것 을 들수 있다. 실례 로 
fs / bfs / inode . c : bfs _ put _ super () 을 들수 있는데 아주 간단하다. 


static void bfs_put_super(struct super_block*s) 
{ 


brelse(s->su_sbh); 
kfree (s->su_imap); 
kfree(s->su_bmap); 

MOD_DEC_USE_COUNT ; 

} 

write_super 

VFS 가 상위블로크로 하여 금 디 스크에 쓰기 를 요구할것 을 결정할 때 호출된다. 호출 
되 는 등록부는 fs / buffer . c : file _ fsync , fs / super . c : sync_supers 와 fs / super . c : do_umount 이 다. 읽 기 전 
용파일 체 계 에 대 해 서 는 필 요없 다는것 이 명 백 하다. 


statfs 

이 조작은 statfs (2) 체 계 호출수행 시 에 요구되며 실행될 때 fs / open.c : sys_statfs 로부터 
호출된 다. 그렇 지 않은 경 우 statfs (2) 는 실 패하며 ermo 를 ENODEV 로 설 정한다. 


remount_fs 

이 조작은 파일 체 계 가 재 올려 태 우기 될 때 즉 MS_REMOUNT 기 발이 mount (2) 체 계 호 
출에 의하여 설정 될 때 호출된다. 또한 파일체 계 를 재올려태 우기하지 않고도 여 러 가지 
올려태 우기 선택 을 변경시 킬 경 우에 리용할수 있 다. 

리용상 공통점 은 읽 기 전용파일 체 계 를 쓰기 가능한 파일 체 계 로 변화시키 는것 이 다. 


clear_inode 

이 선택적인 조작은 VFS 가 색인마디를 지울 때 호출된다. 이 조작은 특별히 
s 仕 uct.inode 의 generic_ip 를 리 용하는 파일 체 계 에 해 당되 는 경 우로서 색 인마디 구조체 에 동 
적배정된 자료를 덧붙일 목적 을 가진 파일체 계 가 요구하는 조작이 다. 이 조작은 현재 색 
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인마디 에 kalloc 로 배정 된 자료를 덧붙이 는 ntfs 와 색 인마디번호를 지 원하지 못하는 파일 
체 계 에서 색 인마디번호가 안정 하다는 가상적 느낌 을 주기 위하여 일 련의 흥미 있는 조작 
을 수행 하는 fat 에 의 하여 리 용되 고 있 다. 

umount_begin 

이 조작은 올려태 우기 를 해 제 하기 위하여 MNT _ FORCE 기 발이 주어 지 면 올려태 우기 
해제프로쎄 스에서 호출된다. 원격봉사기응답과 갈은 어 떤 외부적사건을 기 다리 는 정지상 
태보다는 파일체계상의 어떤 불완전한 거래가 고장을 더 빨리 야기시킨다는데 이 조작의 
취지가 있다. umount_begin 의 호출은 대체로 능동파일체계를 올려태우기해제가능하게 만 
들지 는 않지 만 비종단대 기 에 있는것 보다 오히 려 그 파일체 계를 리용하는 임의 의 파일체 
계 가 파괴될수 있다는데 대 하여 강조해 둔다. 현재 NFS 는 umount _ begin 을 제 공하는 유일 
한 파일체계 이 다. 


성능문제와 최량화방책 

파일체 계성능은 전체 적 인 체 계성능의 주요인자이 며 적재를 동반하는 응용프로그람의 
특성 에 크게 의존한다. 최 량성 능을 얻 기 위하여 토대파일체 계배 치구성은 응용프로그람의 
특성에 맞게 균형 이 이루어 져 야 한다. 만일 사용자자신이 개 발자라면 자기의 응용프로 
그람이 파일체계를 거쳐 읽기나 쓰기를 진행하는 방법에 대하여 이미 잘 알고 있을것이 
다. 하지만 만일 자신이 응용프로그람의 관리자라면 파일체계에 주어 지는 FO 의 형태를 
리해 하기 위하여 응용프로그람을 해 석하는데 일정한 시 간이 걸릴것 이 다. 일 단 응용프로 
그람에 대한 리해를 가지기만 하면 토대계층기억장치를 효과적으로 리용할수 있도륵 파 
일체계 배 치 를 최 량화할수 있 다. 

그와 갈은 객 체 들은 다음의것 들을 들수 있 다. 

▼ 토대층장치들에 대한 I / O 의 수를 가능한껏 줄이는것 

• 가능한껏 작은 I / O 들을 더 큰 I / O 들로 그룹화하는것 

• 디스크찾기를 대기하면서 소비되는 시간을 줄이기 위하여 찾기패턴을 최 량화하 
는것 

▲ 실지적 인 물리 적 I / O 를 줄이 기 위하여 가능한대 로 더 많은 자료를 캐 쉬 에 기 억된 
다는것 

거래를 더 빨리 처리하기 위하여 거래의 서로 다른 부분들이 무엇을 할수 있는가를 
고찰해 야 한다. 

거래는 다음과 갈은것들로 구성된다. 

▼ 거래의 가동일지등록 

• 변경되기전에 변경시켜야 할 주제로 되는 자료의 가동일지등록 

• 기억으로부터 자료기지 레코드에 접근 
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• 자료에 의한 여 러가지 조작 

• 변경이 완료된후 주제가 변경되여 있는 자료의 가동일지등록 
▲ 거래완료의 가동일지등록 


자료기 지 만이 아니 라 사용자등록파일 은 비 휘 발성 기 억 에 보존되 여 야 하므로 상당한 
I/O 수가 요구된다는것을 쉽게 알수 있다. 

원시입출력 (Raw I / O ) 

Linux 에 서 한가지 최 신특성 은 저준위장치 자체 로 곧바로 가지 않으며 캐쉬 들을 
통해 서 접 근이 조종되 지 않는것 들중의 하나인 《 원시》 I / O 의 실현 이 다. 관계형자료 
기 지 관리 체 계 (Oracle, Sybase, Informix DB2 와 기 타 다른 체 계 )들과 같은 몇 가지 응 
용프로그람들은 자체 의 잠금방책 을 관리할수 있기때 문에 원시장치 를 리용하는 쪽에 
더 관심 을 둔다. 보충적 으로 파일체 계실행경 로를 리해하는것도 체 계의 성능을 개선 
하게 한다. 

원시장치 들은 정 교한 응용프로그람들이 자료의 캐 쉬 에 로의 기 억과 일 반화된 
캐쉬에로의 기억의 휴지시간을 줄일수 있는 완전한 조종을 요구하는 경우에 사용 
될수 있다. 원시장치 들은 또한 체 계의 오유사건속에 잃어 진 자료가 하나도 없도 
륵 하기 위하여 디스크에 자료가 즉시에 다씌여 졌다는것을 확인하는 자료-림제- 
상태에 리용되 기 도 한다. 원시장치 자원 에 관한 초기 의 제 안들은 매 개 블로크장치 
들을 원시장치마디 에 주기 위하여 장치마디 의 수를 완전히 중복시켜 야 했 으므로 
적 합 하 지 못 한 것 으 로 간 주 되 였 다 . 많 은 상 업 적 UNIX 들 이 리 용 하 는 방 법 인 
2.4Linux 실현에서는 풀장치마디 를 리용하는데 이 마디 는 어 떤 임 의의 블로크장치 
와 련 관을 가질수 있다. 

이 착상이 더 전진하여 2.4 판본에서는 “kiobuf” 라는 새로운 객체를 포함하게 되였 
다. kiobuf 는 곧 핵심부페지의 임의의 가지에 대한 추상화된 표현인바 이것은 완충기로서 
리 용될 핵 심 부페 지 안의 자유페 지 이 므로 initc 의 코드에 의 하여 기 동시 간내 에 설 정 된 다. 
원 시 ！/ O 는 kiobuf 를 생 성 하고 프로쎄 스가 I/O 로 리용하고 있 는 자료완충기 를 포함하는 물 
리 적페지 들을 가지 는 kiobuf 를 거주시키 는 형 식 으로 작업한다. 정 확한 물리 적기 억폐 지 가 
자료용으로 처리되기만 하면 kiobuf 는 읽기나 쓰기를 위하여 I/O 층에 넘겨 진다. I/O 층들 
은 련관된 페지 들이 사용자프로쎄 스에 속하는가를 알아야 할 필 요가 없 다. 즉 kiobuf 은 
그것 의 구체 적내 용들은 내 부에 숨기 고 있 다. 모든 I/O 층들에 보이 는것 은 물리 적 페 지 들과 
그 페 지 들에 대 한 I/O 요청 들이다. 

프로쎄스자원한계 

프로쎄스의 문맥안에 는 실행시 프로쎄스들이 리 용하는 몇 가지 체 계 자원에 대 한 한계 가 
존재한다. 체계는 이 자원한계 에 의하여 조종되는 매 자원의 기정값과 최대값을 설정한다. 
이 자원한계는 실천적으로 유일한 제한이다. 정의된 매 여섯개의 자원한계에 대하여 기정값 
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을 포함하는 rlim_cur (현재 자원 한계)와 체계에 부과된 자원의 최대값을 포함하는 
rlim_max (최대 자원원천)가 존재 한다. Linux 2.4 에서 프로쎄스당 열 린 파일에 대하여 체계가 
설정한 기 정한계 값은 1024 이 다. 매 프로쎄 스는 어 떤 주어 진 순간에 rlim_fd_cur 까지 만 열 려 
있을수 있다. 

프로쎄 스에 대 하여 열린파일 의 총수는 매 개 프로쎄 스가 생 기 자마자 3 개 의 열린 
파일 을 가지 기때 문에 항상 보충적 인 3 개 의 파일 을 포함한다. 즉 stdin, stdout, stderr (표 
준입 력，출력，오유) 이것들은 모두 프로쎄스를 위한 입 력，출력，오유출력파일을 의 
미 한다. 

shell 에 의 거 하여 uHmit(l) 혹은 limit(l) 명 령 을 리 용하면 rlim_fd_cur 를 볼수 있 다. 

소나 bash 를 리 용하는 사람들은 ulimit(l) 명 령 을 리 용하며 C shell(/bin 八; sh) 를 쓰는 사 
탐들은 limit ⑴을 리용하면 된 다. 


[r 公分 t@hatta /root] # ilimit 

core file size (blocks) 

data seg size (kbytes) 

file size (blocks) 

max memory size (kbyte 3 ) 

stack size (kbytes) 

cpu time (seconds) 

max user processes 

pipe size (512 bytes) 

open files 

virtual memory(kbytes) 


100000C 
unlimit5d 
Unlimitsd 
Unlimit ad 
8192 

Unlimit ad 
2048 
8 

1024 

210534 ： 


rlim_fd_cur 는 “open file” 로 현시되는데 여기서는 그의 기정값(가장 많은 배포판에서) 
은 프로쎄스당 1024 로 보여 주었다. 루트에 관하여 자원한계검사를 하지 않을수도 있으며 
또 열 린 프로쎄 스한계 를 리 론적 으로 3 억 개 (signed int 형 자료의 최 대 값)까지 설 정 할수 있 다. 분 
명히 열려 있는 매개 파일에 요구되는 프로쎄스당 파일구조체를 위한 가상주소공간밖에서 
프로쎄스가 처리되기때문에 이 값에 가까운 그 어떤 값도 엄을수 없다. 또 이 정도로 많은 
파일을 열어야 할 환경에 맞다들리는 일도 물론 없다. 그러나 우리는 프로쎄스당 열린 파일 
의 개수를 수천 혹은 지어 수만개로 설치할 때도 보게 된다. 

동일한 파일 이 그와 관련된 다중파일조종자료구조체를 가질수 있다고 생각해 보겠다. 
만일 같은 체계상에서 실행되는 서로 다른 프로쎄스들이 같은 파일을 연다면 매개 프로쎄 
스는 그 프로쎄스를 정의한 파일조종자료구조체에 대한 파일서술자를 통하여 유일한 파일 
표현을 가지게 된다. 따라서 매개 프로쎄스는 파일을 읽거나 쓸 때 파일조종자료구조체의 
f_offset 수를 변경시키게 된다. 더우기 그 동작이 fork() 나 혹은 clone() 체계호출을 거쳐 계층화 
된 파일서술자와 다르게 되며 또 프로쎄스가 파일서술자의 중복을 위하여 dup() 체계호출을 
내 보낼 때도 달라 진다. 이 순차적서술에서 파일구조체 와 f_offset 마당은 둘다 공유되며 따라 
서 파일에 대한 상위프로쎄스의 읽기나 쓰기는 fork(2) 의 경우에 하위프로쎄스에서 볼수 있 
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는것처럼 그 파일의 f _ offset 를 변경시키거나 혹은 dup (2) 와 dup 2(2) 에 파일서술자에 대한 참 
조값들을 변경시 킨 다. 

범위에 기초한 배정(일반) 

verita 의 VxFS 나 IBM 의 피크와 같은 범위에 기초한 파일배정체계는 디스크블로크를 
범위 로 배정한다. 범위는 배정된 다중블로크들의 련속된 렬을 하나의 단위 로 하여 설정 
하며 파일이 처음에 생성되였을 때 시작되는 론리적변위/길이/물리적길이를 포함하는 
3중구조로 서술된다. 주소화된 구조체는 범위서술자 (3 중)를 가지고 위치한 B + 나무*이며 
색 인마디안에 뿌리화되 여 있고 파일안의 론리 적변위 에 의하여 열쇠화된다. 파일체 계 의 
메타자료 ( meta - data ) 는 파일이 처음으로 생성될 때 기록되는데 블로크에 기초한 배정과는 
다르다. 초기배정 이 순서 화되 여 있기때 문에 그 다음에 수행하는 읽 기，쓰기，찾기 도 물론 
순서적이여야 한다는것이 강조된다. 

첫번째 배정과 블로크범위내 에 다음의 범위 가 배정될 때까지 보충적메 타자료쓰기는 
요구되 지 않는다. 이 방법 은 디 스크찾기 패 턴을 최 량화하며 또 쓰기블로크들을 클라스터 로 
그룹화하는것 은 파일 체 계 로 하여 금 기 억 장치 에 대 하여 수많은 소규모 SCSI 전송휴지 시 간을 
절 약하면서 보다 큰 물리 적 디 스크쓰기 능력 을 발휘 하게 한다. 블로크에 기 초한 배 정 에서 배 
정된 파일의 매개 론리적블로크를 위하여서는 매개 파일에 대하여 수많은 메타자료가 생 
긴다는데 로부터 블로크주소번호가 요구된다. 범위 에 기초한 배정방법 에서 는 매 개 련속된 
자료블로크의 범위 에 대 하여 오직 출발블로크의 번호와 길 이 만을 요구한다. 몇개의 아주 
큰 범위를 가진 그러한 파일은 작은 량의 메 타자료만을 요구한다. 그림 3-5 에서 배정도식 
의 두 방법 즉 블로크배정과 범위배정방법사이의 차이를 보여 주었다. 

범위에 기초한 파일체계는 순차적배정방법과 보다 큰 쓰기용블로크의 클라스터링으 
로 하여 순차파일접근에서 훌륭한 성능을 제공한다. 

실례 로 범위 에 기초한 파일 이라고 해도 순차적 으로 읽 기를 요구하는 경우 시 작블로 
크번호와 그것의 길 이만 읽 으면 된다. 다음부터는 그 범위내 에 있는 모든 자료블로크를 
련속적 으로 읽 을수 있다. 아주 작은 메 타자료의 읽 기경우에 순차적 인 자료의 읽 기는 휴 
지 시간을 산생 시킨다. 그리고 범위 에 기초한 파일체계 는 파일체계 가 우연 I 八)에 리용 


B+ 나무는 물리적주소자료라든가 첨수화된 자료를 포함하는 레코드(잎)를 검사，검색，삽입， 
지울수 있는 특별한 종류의 m- 차균형나무이다. B+ 나무는 잎마디에 의하여서만 지적되는 자료 
를 가지 며 가상적 인 열쇠 를 리용하여 한번 이상 출현하는 검 색열쇠 도 가질수 있 다. 보통 B+ 나무 
는 마디 의 크기 를 폐 지크기 에 의하여 정 의하는 방법 으로 만든다. 탐색경 로가 릉을 따라 가야 
할 때는 폐지화가 요구된다. 자료는 잎에 만 기 억되며 마디 에 는 기 억되지 않는다. 다만 일명 
“read map” 라고 하는 참조열쇠 잎만은 마디 에 보존된다. B+ 나무는 열쇠 를 효과적 으로 찾아 낼 
수 있는 가장 좋은 구조이 다. 그러 나 실제 적 인 문제 는 그것 이 수행하는 3가지 서 로 다른 과제 
로부터 즉 검색，삽입, 지우기로부터 발생한다. 지우기와 검색 이 병행적 으로 진행되는 경우에 
작업의 완료와 완전정지에 빠지는 경우는 50%정도이다. 그러므로 병렬화는 범위에 기초한 파일 
배정체계에서는 그닥 좋은 성능최량화방법이 되지 못한다. 
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붙로보갑당 HflV 양 


그림 3-5. 블로크배정과 범위배정 

될 때에는 효과를 나타내지 못한다. 파일을 우연방식으로 읽을 때는 우리가 블로크에 기 
초한 파일체계 에서 한것 과 류사한 방법 으로 매 개 자료블로크읽 기 를 위하여 요구된 블로 
크의 블로크주소를 검 색하여 야 한다. 

몇 가지 파일 체 계 와 그것 들의 배 정방법 을 아래 의 표에 보여 준다. 


표-1 여러가지 파일체계와 그것들의 배정양식 


파일 체계 

할당 방법 

Ext2 

ReiserFS 

JFS 

블로크에 기 초한 배 정，배정 자는 련속블로크들을 배 정한다. 

범위에 기초한 배정 

범위에 기초한 배정 


블로크에 기초한 배정(일반) 

전통적 인 UNIX 파일 체 계 에 서 리 용한 배 정 방식 은 블로크기 초배 정 방식 이 다. 파일 이 확 
장되 는 경 우에 이 방법 은 파일 에 대 한 최 소블로크수(파일 체 계 에 의하여 정 의 된바와 같이 ) 
를 먼저 배 정한다. 블로크들은 자유블로크로부터 배 정 된다. 이 방법 으로 기 억 공간을 보존 
하려고 할 때 블로크들은 때로 우연순서로 배정된다. 이것은 과도한 디스크찾기를 발생 
시키며 따라서 파일체계로부터의 읽기 에서는 파일의 확장에 따라 배정되는 모든 우연블 
로크위치를 찾아 내기 위한 디스크기술문제가 제기된다. 

우연블로크배 정 은 블로크배 정방법 을 련속된(순서 적 으로) 블로크를 배 정하는 방법으 
로 최 량화하여 극복할수 있고 대략적 인 순차배정은 보다 재치 있는 블로크배정수법을 리 
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용하여 진행할수 있으며 이때 디스크의 찾기시간은 훨씬 감소된다. 하지만 련속된 파일 
체 계 블로크배 정 은 파일체 계 전반에 걸쳐 파일 블로크들을 토막화하는 결과를 초래 하게 될 
것이며 파일체계접근은 결국 우연속성으로 되돌아 오게 될것이다. 블로크배정도식은 매 
번 블로크가 확장될 때마다 새로운 블로크배정에 대한 정보를 기록해야 한다. 어떤 시각 
에 한개 블로크가 확장될 때에는 많은 여유디스크 I/O 가 파일체계블로크조종구조체를 기 
록해 야 한다(파일 체 계 블로크조종구조체 의 정 보는 메 타자료를 말한다.). 

ext 2 파일체 계 에서 메 타자료는 기 억 장치 에 비동기적 으로 씌여 지며 따라서 파일의 크 
기를 변경시키는 조작들은 매 메 타자료조작의 완성 을 기 다릴 필요가 없다. 이것은 파일 
의 갱 신속도를 크게 개선시키지만 실제적 으로 메 타자료를 쓰기전에 파일내 용이 변경되 여 
체 계폭주가 발생하며 모순된 자료로 인한 위 험성 이 커지 게 된다. 

거래처리 훅은 자료기지안전문제 

다중프로쎄 스나 혹은 다중 스레 드로부터 갈은 파일 에 대 한 동기 화된 접 근을 관리할 목 
적 으로 파일 잠금대 면부가 제 공된다. 이 대 면부들은 최근의 서 적 Linux File System 에서 론의 
된다. 련관된 관점으로 볼 때 Linux 혹은 임의의 UNIX 형 OS 는 실제적으로 파일레코드표식 
에 대한 핵심부준위의 지원은 제공하지 않는다. 이 절에서는 정적형，실행기록 ( Journaling ) (실 
행 기록형) 그리 고 사용등록형 (logging ) 파일체계들사이의 차이점 에 대 하여 고찰한다. 모든 자 
료기 지파일들은 파일체 계 에 상주되 여 야 한다. Linux 의 고유파일체 계 즉 ext 2 는 3~4년전까지 
는 여러가지 작업을 원만히 해냈지만 현재 Linux 시장의 도전에 원만히 대응해 나가지 못하 
고 있다. 그 리 유의 하나가 바로 ext 2 가 정적 이라는데 있다. 즉 Linux 는 디스크에 대 한 모든 
갱신작업을 일정하게 진행했다는것을 담보할수 있게 변경사항을 기억하지 못한다. 

더우기 ex 任 fs 는 메타자료를 비동기적으로 기록하는 임의의 OS 우의 몇가지 파일체계 
중의 하나이 다. 이것은 파일연산을 상당한 정 도로 가속화하는 한편 생성，변경날자，소유 
권，허 가 등과 같은 파일 에 대 한 정 보가 파일내 용과 관련 하여 지 연된 형 식 으로 기 록된 다 
는것을 말한다. 파일에 대한 갱신을 기록한 다음 실제적으로 파일머리부를 쓰기전에 성 
능이 저하되면 여기에는 문제가 있는것으로 간주한다. 

ext 2 fs 의 이러한 부족점은 Linux 를 자료기지 봉사기로 광범 히 리 용하는데 서 주되는 장 
애로 되고 있다. 실례로 Linux 용 Oracle 8 i 는 원시！/0를 지원하지 못한다 (2.2 x 핵심부로부터 
는 지 원된 다.). 

Linux 해커들중에는 ex 任免의 이러한 부족점을 고려 하여 실행 기록이나 사용등록파일 체 
계 를 리용하여 해 석하려 는 시 도도 나왔다. 

비실행기록과일체계에 비 한 실행기록과일체계의 우점 

여 기서 고찰하는 실행기록파일체 계 즉 JFS 는 체 계폭주될 때 파일체 계의 재 기동시 간 
을 단축하기 때 문에 인 터네 트파일 봉사기 의 기 본기 술이 다. 

자료기 지 상태 기 록기 술을 리 용할 때 JFS 는 몇 s ， 몇 min 내 로 체 계파일 을 정 상상태 로 회 복 
할수 있다. 비실행기록형파일체계 에서는 파일을 복구하는데 몇시간 혹은 며 칠씩 걸린다. 그 
러므로 실행기록형으로 이전시키는 기술에 의하여서만 체계파일들이 파일을 정상상태로 검 
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증/회복할수 있도록 파일체계의 모든 메 타자료검사에 필요되는 시 간을 줄일수 있다. 

ext2 와 같은 정적파일체계에는 색인마디위치에 관한 배치도가 있다. 이 색인마디들은 
다른 색 인마디 나 매개 파일이름과 관련된 색 인마디들의 표를 포함하는 등록부블로크들과 
자료블로크들을 지 적한다. 

임의 의 UNIX 등록부와 마찬가지 로 Linux 등록부는 파일 이 름과 색 인마디번호사이의 
관계 이 다. 파일의 색 인마디번호는 Is 명 령 에 “_i” 스위 치 를 주어 찾아 볼수 있다. 색 인 
마디는 디스크상에 파일에 관한 자료블로크가 어디에 있는가를 지적하는 지적자와 함 
께 소유권과 허 가정 보를 포함한다. 이 제 어 떤 파일 “test.file” 의 내 용을 변경시 킬 때 
어떤 일 이 생기는가를 보자. “test.file” 을 위한 색 인마디 가 4 개의 자료블로크를 목록 
화하고 있다고 가정하자. 

“test.file” 의 자료는 디스크위 치 3110, 3111, 3506, 3507 에 존재 하고 있 다. 디스크블 
로크의 초기 배정시에 3111 과 3506 사이에는 다른것들이 이미 배정되였으므로 간격이 생 
기 게 된다. 이 때 우리 는 이 파일 이 토막화된 다고 본다. 하드구동기 는 디 스크면우에 서 
3110 구역을 찾아야 하며 거기서 두개 블로크를 읽고 다음 3506 구역을 찾고 전체 파일을 
읽기 위하여 두개의 블로크를 읽어야 한다. 

이 제 세번째 블로크를 변경시켜 보자. 변경 에 따라 파일체 계 는 세번째 블로크를 읽 
고 재쓰기를 진행하는데 여전히 3506 을 가리킨다. 파일을 첨 가하면 임의의 곳에 블로크 
가 배정될수 있다. 전원이 불결하면 위험이 동반된다. 등록부의 갱신동작이 절반단계에서 
진행 되 고 있 다고 가정 하자. 큰 등록부의 다섯 번째 블로크에 있는 23 개 파일입 구점 을 교 
정한다. 디 스크가 이 블로크에 대 한 쓰기작업 도중에 있기때 문에 전원이 중단되 면 블로크 
는 완성되지 못하며 따라서 자료가 손상되게 된다. 

재 기 동시 Linux (모든 UNIX 와 같은)는 fsck (파일 체 계검 사 ) 프로그람을 실 행한다. 이 프 
로그람은 전체 파일체계에 걸쳐 모든 입구점들의 정확성을 검증하고 블로크들이 정확하 
게 배정 되 고 참조되 는가를 확인하는 작업 을 단계 적 으로 수행한다. 

이 프로그람은 손상된 등록부의 입 구점 들을 찾고 그것 을 재 생하려 고 하지 만 fsck 가 
실제적으로 손상회복을 관리한다는 확신성은 어디에도 없으며 흔히 실제적으로 그렇게 
되지 않는다. 때때 로 우에서 설명한것과 같은 조건에서 모든 등록부입구점들은 루실될 
수 있다. 큰 파일체 계들에서 fsck 의 실행 에는 아주 긴 시 간이 걸릴수 있다. 수기 가바이 
트정도의 파일을 가진 기계에서 fsck 는 10h 혹은 그이상 시간까지도 수행될수 있다. 물 
론 이 시간동안 체계를 리용할수 없으며 이것은 허용할수 없는 휴식시간으로 된다. 

실행기 록형파일체 계는 이 문제를 해결하지 만 또 새 로운 문제 를 산생시킨다. 어떻 게 
발생하며 왜 그렇 게 되 는가를 보자. 

실행기록형파일체계의 동작 

실행기 록형파일체 계 (JFS) 는 초기 에 자료기지 가 파일체 계메 타자료에 대 하여 수행 되는 
조작에 대한 정보를 최소거래로 등록하도록 개발된 기술이 다. 체계고장사건시 파일체계 
는 가동일지 (log) 들의 재생과 적당한 거래에 가동일지기록을 적용하는 방법으로 정상상태 
로 회복된다. 이러한 가동일지기초형방법과 련관된 회복시간은 재생편의프로그람이 파일 
체 계 메 타자료 전체 를 검 사하지 않고 최 근의 파일 체 계 동작에 의 하여 생 성 된 가동일 지 기 록 
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만을 검사해야 하기때문에 대단히 빠르다. 

JFS 와 같은 실행기록형파일체계는 구조적정확성과 회복성이 개선되였으며 HPFS, 
ext2 그리 고 전통적 인 UNIX 파일체 계 와 같은 비실행기록형파일체 계보다 회 복시 간이 매우 
빠르다(피크는 수 s 혹은 수 min 내 에 체 계파일 을 정 상상태 로 회 복한다.). 

다른 체 계파일 들은 론리 적파일 쓰기조작이 흔히 다중매 체 I / O 에 서 이 루어 지 게 되 고 
전체적으로 어떤 주어 진 시간내에 반영되지 않기때문에 체계고장사건시 에 디스크자료손 
상이 있게 된다. 

이 러한 파일체 계들은 등록부와 디스크주소구조체 와 같이 구조적 인 종합문제들을 검출하 
고 회복하기 위 한 모든 파일체계의 메 타자료를 검사하는 재시동-시 간편의프로그람들 (Linux 에 
서는 보통 feck 를 의미 한다.)에 의존한다. 이 편의프로그람은 극단한 경우에 자료를 잃거 나 틀 
리게 할수 있는 시간소비지향 및 오유지향성프로쎄스로 될수 있다. 실행기록형파일체계들은 
색 인마디 의 변경 만을 계 속 보존하지 만 파일의 내 용은 변경 시 키 지 않는다. 따라서 파일체 계 의 
사용등록은 자료와 색 인마디 에서 이루어 진 변경들을 둘다 계속 보존한다 . 모든 변경들과 추 
가，지우기들은 가동일지처리로 알려 진 파일체계의 특정한 부분에 등록된다. 

“testiile” 에 의한 첫번째 실례 에서는 3506 블로크에 있는 자료를 변경시키지 않고 
등록파일 체계 (log file system) 가 “test.file” 과 디스크상의 새 위치에 있는 세 번째 블로크 
의 색 인마디 들의 복사를 기 억하게 된 다. 

색 인마디 들의 기 억 목록은 “testfile” 을 새 로운 색 인마디 로 지 적하게 끔 변화된 다. 이 
따금 파일체계는 디스크상의 색인마디목록을 검사하거나 갱신하며 리용되지 않은 파일부 
분을 공간으로 남긴다 ( “testiile” 의 첫 세번째 블 로크 ). 

등록파일 체 계 는 디 스크의 동일한 구역 에 대 하여 서 만 추가동작을 하며 그우에 서 
블로크들을 여기저기 찾을 필요가 실제적으로 없기때문에 쓰기속도가 비약적으로 높 
아 진다. 그러므로 쓰기속도가 개선되며 회복시간도 역시 줄어 든다(실제적으로 구조적특 
성으로 하여 회복시간이 전혀 없다.). 

정 적파일체 계 에 비 하여 등록파일체 계 는 파일 자료블로크들을 쉽 게 찾을수 있기 때 문에 
거 의 동일 한 읽 기 속도를 가진 다. 색 인마디 배 치 도는 블로크들의 목록으로 구성 되 고 목록 
들은 보통 기억넘기기되기때문에 빨리 읽을수 있다. 

따라서 등록파일체계는 가장 훌륭한 측면을 가지고 있다고 볼수 있다. 읽기시간은 
정 적파일 체 계 와 거 의 동등하다(토막이 많기 때 문에 아마 비 트속도는 더 늦어 질 수 있 다. 
등록파일체계에서 중요한 문제는 쉽게 토막화될수 있다는데 있다.). 

등록파일체계의 일반적 형태 

파일체계가 디스크구조체로 변화될 때는 변화시키는데 필요한 몇개의 차단된 동기적 
인 쓰기 를 리 용한다. 만일 조작도중에 중지 가 발생하면 파일 체 계 의 상태 는 미 정 으로 되 
며 전체 파일체계에 대하여 일관성을 검사해야 한다. 만일 한개 블로크를 파일의 끝에 
추가할 때 파일의 매 블로크가 어디에 위치하고 있는가를 통지하는 디스크넘기기가 자 
료블로크를 쓰기전에 디 스크를 읽 거 나 변경 시 켜 야 하며 재기 록해 야 한다. 

오유가 발생할 때 파일체 계 는 기동하여 올려태우기되 기전에 검사되 여 야 하는데 이때 
파일체계관리기는 블로크넘기 기가 정확한지 알지 못하며 또 폭주시 에 어느 파일 이 변경 
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되였는지 모른다. 

이때 는 완전한 파일체계 주사동작으로 넘 어 간다. 메 타자료등록파일체 계는 디 스크상 
에 wrap - around 추가전용등록구역을 가지고 있 다. 

이 구역 에서 파일체계는 매 개 디스크거래의 상태를 등록하는데 리용한다. 어떤 디스크 
구조체 가 변경 되 기 전에 intent _ to _ commit 레 코드가 가동일지 에 기 록된 다. 이 때 등록부구조체 
는 갱 신되며 가동일지입 구점 은 완전히 표식 화된다. 파일체 계구조체 에 대 한 매 개 변경 이 가 
동일지 에 있기때문에 완전파일체계 주사를 요구하지 않고도 가동일지를 보고 파일체계의 
일 관성 을 검 사할수 있 다. 올려 태 우기 시 에 indent _ to _ commit 입 구점 이 보이 지 만 완전히 표식 
화되지 않았으면 블로크용파일구조체가 검사되며 필요한 경우 고쳐 진다. 

그림 3-6 은 정규파일(정적)체계 즉 ext 2 fs 에서 파일의 자료블로크와 색인마디정보(변 
경 시 간，자료블로크에 대 한 지 적 자 등) 그리 고 파일 에 서 자료를 변경 시 킬 때 어 떤 일 이 
발생하는가를 보여 준다. 



그림 3-7 은 등록파일체계 에서의 류사한 파일과 그것 이 변경될 때 어 떤 일 이 생 기는 
가를 보여 준다. 

변화되는 매개가 가동일지의 끝에 추가된다는것을 강조한다. 이 방법은 파일부분들 
에 쓸 때 디스크전체를 찾을 필요가 없기때문에 속도가 빠르다. 

또한 가동일지가《새》자료블로크들을 성공적으로 쓸 때까지 파일의 초기자료블로크 
를《잊어 버러지》않기때문에 아주 안전하다. 이것은 폭주후에 fsck 시간이 거의 필요없이 
아주 안전한 파일체계를 유지할수 있게 한다. 이 러한 파일체계들은 마지막검사점 이 검사된 
후 파일체계만을 갱신하기때문에 폭주후 거의 즉시적으로 직결상태로 돌아 온다. 

가동일지안에서 모든 변경이 빨리 재적용되여 디스크의 손상된 부분은 언제나 가동일지에 
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그림 3-7. 사용등록파일체 계 에서 갱 신조작 

첨가된 마지막변경으로 된다. 이 변경내용은 무효한것이므로 버릴수 있다. 전원차단시에 
잃어 진 자료는 하나의 내용만 변경된다. 

20 GB 의 메 타자료등록파일체계와 그이상의 체계들에서는 대표적으로 폭주후 fsck 와 
회 복에 4~5 s 정 도 걸린 다. 따라서 메 타자료등록파일 체 계 는 몇초동안에 올려태 우기 되 는 아 
주 대 중화된 파일 체 계 와 수십 혹은 수시 간 올려태 우기되 는 등록 없는 체 계 사이 에 차이 가 
생기게 한다. 그럼 에도 불구하고 사용등록은 자유롭지 못하며 여기 에도 무시할수 없는 
성 능상의 휴지시 간이 존재 한다는데 대 하여 주의 를 돌려야 한다. 

사용등록은 느린 동기적쓰기 들을 더 많이 요구하며 가장 일 반화된 등록의 실현인 
메타자료등록도 파일갱신에 적어도 3개의 쓰기를 요구한다. 이것은 사용등록없이 진행 
할 때 보다도 더 많다는것 을 의 미한다. 

결과적 으로 우리 가 요구하는것 이 무엇 인가에 대 하여 주의 를 돌려야 한다. 즉 파일 
체계의 속도를 빨리 할것을 요구하는가 혹은 실현성을 최대로 할것을 요구하는가에 
대 하여 주의 를 돌려야 한다. 

몇 가지 등록파일체 계 들은 가동일 지 에 메 타자료와 함께 파일자료로 설 정하는 선 
택항목을 제공하고 있으므로 여기서는 두번찾기와 쓰기를 피할수 있다. 

자료는 처음에 가동일지 에 씌여 지고 다음에 파일체계안에 반복한다. 

이 조작은 두가지 일 을 수행한다. 

우선 포함되지는 않지만 마지막블로크까지 씌여 진 자료의 완전성을 확인한다. 

또한 전자우편이 나 새 소식 봉사기 에서 와 같이 소규모동기 쓰기 의 성 능을 발휘하게 한다. 
그렇지 않은 경우에는 매개의 응용프로그람쓰기에 대하여 디스크의 서로 다른 부분에 둘 
혹은 그이 상의 쓰기 가 요구된 다(자료를 위한 쓰기 와 사용등록기 록을 위한 쓰기). 
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제 4 장. 가상파일체계 VFS 

이 장에서는 Linux 가상파일 체 계 ( VFS ) 에 대 하여 3장에서 일반적으로 고찰한 내용들을 
보다 상세하게 취 급한다. 

Linux 파일체계에 대하여 정확히 리해하자면 핵심부와 대면부에 대하여 완전히 파악 
하여 야 하는데 그러한 대 면부가 바로 가상파일 체 계 이 다. 

UNIX 형 OS 에 서 와 같이 Linux 는 VFS 를 가지 는데 오랜 시 간이 걸 렸 으며 Free 
BSD 조작체계들을 비롯하여 Solaris , AIX , HP _ UX 들도 모두 류사한 VFS 를 가지 고 있 
었다. 여기에서 주목되는것은 Linux 만이 가장 최신형의 VFS 를 가지고 있다는것이다. 

Linux 계 통의 연구자들은 오래 동안 프로그람을 작성 하고 많은 의 견들을 종합처 리하여 
설계 를 완성 함으로써 새 로운 판본 2.4.0 으로서 LinuxVFS 를 완성하였다. 

일반적 개 념 

Linux 에 서 모든 파일 들은 가상파일 체 계스위 치 혹은 VFS 에 의하여 접 근된 다. VFS 는 
일 반적파일체 계기 능과 요청 을 조종하기 위하여 정의 된 정 확한 코드들에 대 한 벡 토르요청 
을 실현하는 코드의 한 계 층이 다. 임의의 형 태의 파일체 계 들은 블로크장치접 근을 실현하 
기 위하여 VFS 를 리용한다. 

VFS 의 원천쿄드 

제2장 《Linux 핵심부를파일》에서 고찰한바와 같이 VFS 의 원천코드는 캐쉬 
와 실행가능한 모든 파일형식을 취급하는 코드와 갈은 몇가지 관련된 부분들과 
함께 Linux 핵 심부의 원천부분등록부 fs / 에 존재한다. 매 정의된 파일체 계 는 보다 
낮令 부분등록부에 보관되 는데 례 를 들어 ext 2 파일체 계원천코드는 fs / ext 2/ 에 보존 
된 다. 

다음의 표는 fs 부분등록부의 파일 이 름과 그 매 개의 기 본목적 을 설명한다. 중간 
렬 즉 표식화된 체계는 파일이 결정되는(기본적으로) 기본부분체계가 어느것인가를 
보여 주었 다. EXE 는 실 행 가능한 파일 을 인식 하고 적 재하는데 리용된 다는것 을 의 미 
한다. 

DEV 는 장치구동기지원에 리용된다는것 을 의미하며 BUF 는 캐쉬를 의미한다. 

VFS 는 VFS 의 한 부분이 며 파일 체 계 정 의 코드에 관한 몇 가지 기 능성 을 대 표한다는것 
을 의 미한다. 

VFS 는 또한 이 코드가 완전히 고유하며 정 의된 파일체 계코드에 관한 그것의 조작 
부분을 절대 로 대 신할수 없다는것을 의 미한다. 

하지 만 파일체 계를 쓰는데서 이 러 저 러한 걱정은 하지 않아도 된다. 
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VFS 으 I 동작 


앞에서 언급한바와 같이 Linux 가상파일체계는 아무것도 하지 않지만 파일체계와 관 
련되 는 모든 체 계호출을 중간에 서 취 하는 하나의 계 층이 다. 그러 므로 VFS 는 모든 파일 
체계에 대한 표준적인 대면부(혹은 API ) 를 제공해야 한다. 사실 Linux 상에서 ISO 9660 CD - 
ROM 이 나 DOS 형 식플로피 디 스크의 내 용을 목록으로 연시할 때 (즉 Is ) 나 /boot 등록부를 보 
기 위한 명 령 들사이 에 는 아무런 차이 도 없 다. 

이러한 공통적인 대면부를 얻기 위하여 VFS 는 공통파일모형을 도입하였다. 이 모형 
은 응용프로그람에 대하여서는 모든 파일체계들이 서로 곡 갈은것으로 볼수 있게 한다. 
이 모형 은 또한 ext 2, JFS 혹은 다른 그 어 떤 파일체 계 든지 개 별적파일체 계 들에 이 르기까 
지 VFS 의 요구에 대 한 파일의 리해를 서 로 번역할수 있게 해준다. 

VFS 공통파일모형에서 등록부들은 마치 다른 파일이나 다른 등록부의 목록을 포함하 
고 있는 파일인것처럼 보인다. 몇가지 파일체계 즉 FAT , FAT 32, VFAT 와 같은것들은 등 
록부나무안의 매 파일의 위 치를 기 억하며 그 경우에 등록부들은 표준파일로 되지 않는다. 
따라서 이 파일체계들은 파일체계상에서 동작할 때의 파일처럼 동적으로 등록부의 보기 
기능을 실현해야 한다. 

분명 히 그러한 보기기능들은 파일체계안에는 기 억되지 않으며 핵심부의 공간에 객체 
로서 만 존재한다. 

더 론의 하면 Linux 는 실제적으로 실제적핵심부함수안으로 파일관련체계 호출을 실행 
하지 않는다. 한편 read () 나 ioctl () 은 제기된 문제에서 파일을 조종하는 매개 파일체계에 
대 하여 정 의하는 함수에 대 한 지 적자로 변환된 다. 

이 기 능을 실 현 하기 위하여 VFS 공통파일 모형 은 매 개 파일 체 계 가 UNIX 의 전통적방법 
에 대 응시 키 는 일 련의 파일 체 계 조종블로크들에 대 한 표기 를 도입하였 다. 

이 조종블로크들과 구조체들에는 다음과 갈은것들이 있다. 


상위 블로크구조체 

올려 태우기된 파일체계에 대한 정보. 이 구조체는 보통 장치 
에 기 억된 파일 체 계 조종블로크를 정 합시 킨다. 

객 체 

정의된 파일에 대한 정보. 보통 이 정보는 디스크상의 파일 
조종블로크를 지적한다. 이 매개 객체들은 색 인마디번호를 
가지며 이 번호는 해 당 파일체계 안의 파일을 유일적 으로 지 
적 한다. 

파일 객체 

현재 열려 진 파일과 거기에 접근하는 프로쎄스에 대한 정 
보. 이 구조체는 핵심부에만 보존되여 있으며 파일닫기상태 
에서는 나타나지 않는다. 

덴트리객체 

등록부의 입구점과 관련된 파일내의 련결에 대한 정보. 매개 
파일체계에서 이 련결실현과정은 서로 다르다. 


앞에 서 본바와 같이 VFS 는 공통계 층을 생 성하는데만 제 한하지 않는다. VFS 는 덴 트 
리캐쉬를 리용하여 파일체계의 성능을 최대로 높일수 있게 한다. 이 캐쉬는 파일자체의 
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• 매우 가속화한다. 

VFS 는 또한 디스크캐쉬도 유지관리한다. 이 캐쉬는 가사 
가상기 억 에 는 디 스크캐 쉬 에 기 억 된 정 보의 리 용을 고속화 
예 가 디 스크상에 표준적 으로 기 억된다. 덴트리캐쉬외 에 L 
서의 캐쉬도 있다. 두개의 캐쉬는 앞부분에서 설명하였匕 

VFS - 조종체계호출 

파일 이 나 파일 체 계 를 취 급하는 일 부 체 계호출은 추상화된 
:하는 실제 적파일체 계정의 로 변환할수 있도륵 VFS 가 중간어 


다 음의 표 에 서 지 적 한 것 외 에 bind (), connect (), ioperm (), ioctl (), pipe (), socke 
od () 체 계호출들도 역 시 VFS 층에 의하여 조종된 다. 


체계 호출 

기 능 

chroot () 

뿌리등록부를 변경 

chmod (), fchdir (), getcwd () 

현행등록부를 변경 

dup (), dup 2(), fcntl () 

파일서술자조종 

fdatasync (), fsync () , sync (), msync () 

완충기의 동기화 

lseek (), _ lseek () 

파일변위를 변경 

mount (), umount () 

파일 체 계 의 올려 태 우기 와 올려 태 우기 해 제 

getdents (), readdir (), link (), unlink (), 
rename () 

련결조종 

readlink , symlink () 

쏘프트련결조종 

read (), write (), readv (), writev (), 

sendfile () 

파일 I/O 

pread (), pwrite () 

파일찾기와 I / O 조종 

mmap (), munmap () 

기억에로의 파일넘기기 

flock () 

파일 잠금 

stat (), fstat (), lstat (), access () 

현재파일상태에 접근 

truncateO , ftruncate () 

파일의 크기변경 

open (), close (), creat (), umask () 

파일의 열기와 닫기 

select (), poll () 

비동기 I / O 조종 

sysfs () 

파일체계에 대한 일반적정보 

statfsf ), fstatfsf ), ustat () 

파일체계 에 대 한 통계 자료읽기 




이것들에 대해서는 이 장의 뒤부분에서 따로 설명한다. 

덴트리캐쉬 

앞부분에서는 핵심부안의 가상기억관리기가 블로크장치용 두개의 캐쉬 즉 완충 
고속기억기와 페지에서의 고속기억기를 어떻게 관리하는가에 대하여 보았다. Linux 
의 VFS 층에 의하여 관리 되 는 캐쉬 들중의 하나가 덴트리캐 쉬 이 다. 파일 이 름에 대 한 
대응하는 색인마디의 검색은 장치에로의 접근을 요구하며 특히 경로이름이 복합화 
된 경우에는 성능상의 견지에서 매우 경제적이다. 이 사실은 가장 최근에 검색된 파 
일 의 캐 쉬 와 경 로 그리 고 색 인마디번 호들을 관리해 야 할 요구를 제 기 하고 있다. 이 
캐쉬를 바로 덴트리캐쉬라고 부른다. 

덴트리캐쉬는 두개의 주요자료구조체 로 구성된다. 

▼ 사용되였거나 사용되지 않은 부의 상태에 있는 덴트리객체들의 목록 

▲ 파일 이 름에 대 한 덴트리객 체 들과 그것 의 등록부를 빨리 찾기 위한 하쉬표 

Linux 에서 덴트리캐쉬함수는 역시 색 인마디캐쉬 이 다. 덴트리캐쉬의 색 인마디 는 여 전 
히 사용되지 않은 덴트리와 관련되며 지워 지지 않고 쉽게 보존된다. 

《 U 況 D 》 라는 기발로 표시되는 모든 덴트리들은 련관된 색인마디객체의 덴트리마 
당에 대하여 지적되는 2중련결목록으로 유지된다. 이 덴트리들은 한점 혹은 다른 점에서 
《부》로 될수 있는데 이것은 마지막고정련결이 제거될 때이다. 이러한 상태가 발생할 
때 객체는 LRU 목록으로 옮겨 진다. LRU 목록은 모든 개별화된 덴트리객체에 대한지적 
자를 포함하는 시간에 따라 정렬된 2중련결목록이다. 

핵심부의 VM 관리기 가 덴트리캐쉬를 줄여 야 한다는것을 결정하면 덴트리캐쉬는 
LRU 목록으로부터 가장 오래된 덴트리객체를 지우는것으로부터 시작한다. 

덴트리 객 체 를 취 급하는 원천코드안의 함수들은 덴트리함수라고 부론다. 이 것 들은 모 
두 dentry _ operation 자료구조체 를 리 용한다. 그것 들의 주소는 d _ op 마당으로부터 얻 어 낼 수 
있 다. 

몇 가지 파일 체 계 ( NFS 와 같은)는 자기 의 고유한 덴트리 조작을 수행한다. 이 경 우에 우 
에서 언급된 파일들은 비 워 지 게 되 며 VFS 는 그대 신 기정 기 능을 수행한다. 

덴트리 캐 쉬 가 리용하는 기 본함수들은 다음과 갈다. 
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덴트리캐쉬기능 

목 적 

d_compare(dir, namel,name2) 

인수에 주어 진 두개의 파일이름을 비교한다. 이 
함수는 파일 체 계의 존형 이다. FAT 파일 체 계 는 비 교 
시 대문자와 소문자를 구별하지 않는다. 

d_delete(dentry) 

덴트리 에 대 한 마지 막참조를 제 거한후 이 함수가 
호출된 다. 

d_hash(dentry,hash) 

특정한 덴트리객체에 대한 하쉬값을 계산한다. 

이 함수는 파일 체 계의 존형 이다. 

d_iput(dentry, ino) 

덴트리를《부》로 표시하고 LRU 에로 그것을 옮 
긴 다. 

d_release(dentry) 

덴트리객체를 목록에서 지운다. 

d_revalidate(dentry) 

변환에 리용하기 전에 특정한 덴트리 가 아직 유효 
한 상태에 있는가를 검사한다. 


파일체계올려태우기 


핵심부는 기동시나 혹은 올려태우기명령에 의하여 표준조작을 진행하는 과정에 - 
斗일체계 를 등록한다. 이 미 본바와 같이 올려태 우기 는 VFS 층에 의하여 실행되 고 
한 명 령 들중의 하나이 다. 매 개 파일체 계는 그자체의 뿌리등록부를 가져 야 한다(이 
귀 환장치 들에 서 도 마찬가지 이 다.). 

init_name_fs() 를 위 한 임의의 파일체 계의 코드를 보면 대체 로 한행정도의 코드 1 
■고 있다는것을 알수 있다. 실례로 extfs 에서 다음과 같이 된다 (fs/ex 任/ super.c 로부터 

int init_ext2_fs (void) 

{ 

return register_file system(&ext2_fs_type); 

} 

이 조작은 분명 히 fs/super.c 에 보존된 레 지 스트리 에 의 하여 체 계 파일 을 등록하는 
다. 


ext2_fs_type 는 실지 로 아주 단순한 구조체 이 다. 



실례에서 “ ext 2” 은 파일체계의 형이름인데 이것은 장치를 올려태우기할 때 어느 파일 
체 계 를 리 용하겠는가를 결 정 하는데 리 용된 다. 보통 체 계 관리 기 는 “_ t ” 선택 을 가진 올려 
태 우기명 령 으로 파일 체 계 를 지 적한다. 

실례 로 mount_t jfs / dev / sdal/diskl 은 JFS 파일체 계 를 지 적 한다. VFS 는 올려 태 우기 될 상위 블 
로크로부터 체 계 파일 을 검 출할수 있는 능력 을 가지 고 있 다. 따라서 mount _ a / dev / cdrom/mnt 
은 대 다수의 핵 심 부들에 서 리용될 수 있다. “1” 은 장치 가 올려태 우기될 것 을 요구하며 
( proc . 파일체계나 망파일체계에서는 다르다.) NULL 은 공간을 채울것을 요구한다는것을 
의 미한다. 이때 채워 질 공간은 fs / super.c 에 보존된 파일체 계레지스트리안의 파일체계형 
의 련결목록을 보존하는데 리용된다. 한개 파일체계가 하나이상의 파일체계형을 지원할 
수 있다. 실례 로 fs / sysv / inode.c 에 있는 3개의 가능한 파일체 계형은 다음의 코드로 하나의 
파일 체 계 에 의하여 지 원된 다. 


static struct file_system_type sysv_fs_type[3]={ 

{sysv_read_super, “xenix” , 1 , NULL}, 

{sysv_read_super, “sysv” , 1 , NULL}, 

{sysv_read_super, “coherent” , 1 , NULL} 

}； 

int init_sysv_fs (void) 

{ 

int i; 
int ouch; 

for (i=0; i<3; i++){ 

if ((ouch=register_file system(&sysv_fs_type[i])) 

!=0)return ouch ; 

} 

return ouch 

} 

파일체계와 디스크의 련결 

핵심부와 파일체계는 오직 파일체계의 형이 부여된 장치가 올려태우기될 때만 서 
로 작업 하기 시 작한다. 체 계관리기 가 ext 2 파일 체 계 를 포함하는 장치 를 올려태 우기할 
때 super.c (이 장의 마지 막에 서 술된)로부터 ext 2_ read _ super () 가 호출된 다. 상위 블로크 
의 읽기 가 성공적으로 진행되고 파일체계를 올려태우기할수 있으면 super_operations 라고 
부르는 구조체 에 대 한 지 적 자를 포함하는 정 보를 super_block 구조체 에 써 넣 는다. 

이 때 super_operations 는 상위 블로크와 관련된 공통적 조작을 수행 하는 함수들에 대 한 
지 적자를 포함하고 있다. 즉 이 경 우에 는 ext 2 에 정의한 함수들에 대 한 지적자를 말한다. 

상위블로크는 장치 에 관한 모든 파일체 계 를 정 의하는 블로크이다. 물론 상위블로크 
를 가지 고 있지 않는 파일체계도 있다 (FAT 체계와 같은). 
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총체 적 으로 파일 체 계 에 속하는 조작들은 상위 블로크조작으로 고찰할수 있 다. 

super_operations 구조체 는 색 인마디 와 상위 블로크를 관리 하는 함수들에 대 한 지 적 자를 
포함하는데 그것 은 전체 로서 파일체 계의 상태 를 참조하거 나 변경시 킬수 있다 (stetfsO 와 
remount ()). 

유감스럽 게 도 핵 심 부개 발은 많은 지 적 자들을 동반하기때 문에 파일체 계 개 발자들은 가 
상파일체계의 능력을 그 지적자들을 정확히 해결하는데 힘을 넣어야 한다. 

새로운 파일체계 에 대 하여 프로그람작성 자가 요구하는 모든 내용은 함수에 대 한 지 
적 자로서 구조체 (보통 정 적 )에 들어 가 있 으며 이 구조체 에 대 한 지 적 자는 VFS 로 다시 넘 
겨 지며 따라서 파일체계와 파일에서 그것을 얻어 낼수 있다. 

실례로 상위블로크구조체는 VFS 에서 다음과 같이 볼수 있다. 

struct super_operations { 

void(*read_inode) (struct inode*) ; 

int(*notify_change) (struct inode*, struct iattr*) ; 

void(*write_inode) (struct inode*) ; 

void(*put_inode) (struct inode*) ; 

void(*put_super) (struct super_block*) ; 

void(*write_super) (struct super_block*) ; 

void(*statfs) (struct super_block*, struct statfs*, int) ; 

int(*remount_fs) (struct super_block *, int*, char*); 

}； 


fs / ext 2/ super . c 에 서술된 ext 2 에서의 선포문에 대하여 비교해 보자. 


static struct super_operations ext2_sops= { 
ext2_read_inode, 

NULL, 



ext2_statfs, 
ext2_remount} ; 


일부 사용자들의 경우 NULL 입구점 이 무엇 인가에 대 하여 대체 로 의문을 가질것 이다. 
Linux 전반에 걸 쳐 함수지적 자를 얻 기 위하여 어 떤 기 정 동작이 요구될 때 마다 NULL 지 적 
자는 그 요구를 만족시 킬수 있는 편리한 수단이 다. 
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우의 선포문에서 문장구분이 얼마나 간단하고 명백한가를 알수 있다. 
sb -> s _ op - write _ super ( sb ) 와 같은 모든 코드들은 VFS 의 실현부안에 숨겨 져 있다. 

파일체 계들이 상위블로크를 포함하여 디 스크로부터 실제적 으로 블로크들을 어 떻게 
읽 고 쓰는가에 대 한 구체적 인 내용은 이 책의 마지 막장들에서 론의한다. 캐쉬의 실현은 
이미 3장에서 고찰하였다. 

파일체계의 올려대우기 

파일 체 계 가 올려태 우기 될 때 (참조를 쉽 게 하기 위하여 이 장의 마지 막부분에 인쇄해 
넣 은 fs / super.c 에 의 하여 수행된다.) 실행되는 사건렬은 다음과 같다. 


1. do _ umount () 

2. read _ super () 

3. ex 任 _ read _ super()(ex 任파일체계의 경우) 

이 것 들은 상위 블로크를 귀 환시 킨다. 상위블로크는 우의 ex 任 _ SO p S 에 서 볼수 있는 함 
수들에 대 한 지 적 자구조체 에 대 한 지 적자를 포함한다. 

다른 중요한 자료를 포함하는데 그것들의 정의는 이 장의 마지막에 주었다. 

파일에로의 접근 

일 단 파일체계 가 제 대로 올려태우기되면 거기서 파일로 접근할수 있다. 파일에로 접 
근하는데는 두개의 동작이 필요하다. 

1. 어 느 색 인마디 를 지 적하는가를 찾기 위 한 이 름의 검 색 

2. 색인마디에로의 접근 

VFS 가 이름을 찾으면 그 이름에는 경로가 포함되여 있다 (3 장을 볼것). 따라서 파일 
이 름이 절대 적 이 아닐 때는 경 로가 7” 문자로 시 작되며 그것은 체 계호출이 진행되는 
현행등록부와 관련되 게 된다. 다음으로 핵 심 부는 정 의된 파일체 계안의 파일을 검 색 하기 
위하여 체 계정의코드를 리용하게 된다. 

계속하여 경로이름의 요소를 엄고 그것을 검색한다. 만일 검색한 객체가 등록부이면 
먼저 검색한 객체 에 의하여 귀환된 등록부안에서 검색한다. 검색된 매 요소는 그것 이 파 
일이든지 등록부이든지 관계없이 객체를 일의적으로 식별할수 있는 색인마디번호를 귀환 
하며 귀 환된 그 내 용에 의하여 접 근할수 있다. 만일 파일 이 다른 파일 에 대 한 기 호적련 
결로 전환되면 VFS 는 기호적련결로 검색되는 새로운 이름으로 시 작한다. 무한재귀를 방 
지하기 위하여 기호련결의 깊이 ( depth ) 에 한계를 준다. 즉 핵심부는 내리기에 앞서 한행 
에서 몇개의 기 호련결을 추적하게 된다. 

namei () 는 이 름을 색 인마디 번 호로 대 응시 키 는데 리 용된 다. open _ name () 함수는 이 책 
의 마지막부분에 포함되여 있다. 
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일 단 색 인마디번호가 엄 어 지면 그 파일에 접근할수 있다. Iget () 함수는 색 인마디번호 
에 의하여 정의되는 색 인마디를 찾아서 귀 환시 킨다. Iput () 함수는 색 인마디 에 대 한 접근을 
해제 하기 위하여 그다음에 리 용된다. 이 내 용은 한개 이상의 프로쎄스가 한번에 열 리는 
색 인마디 를 한개 만 보관할수 있다는것 을 제외 하고는 malloc (), free () 와 갈으며 참조계수값 
은 그것이 비여 지거나 없어 지는 시각을 알아 내는데 리용된다. 

응용프로그람코드로 되넘겨 지는 옹근수파일핸들은 그 프로쎄스에 해당한 파일표에 
로 접 근하기 위한 변위값이 다. 이 파일표슬로트는 파일 이 닫겨 지거 나 프로쎄 스가 완료 
될 때 까지 namei () 함수로 검 색된 색 인마디 번호를 보존한다. 프로쎄 스는 파일핸들을 리 용 
하는 “파일 ” 에 대 하여 그 어떤 일을 할 때마다 그 문제안에서 색 인마디는 실제적 으로 
조종된다. 

색인마디조작 

앞에 서 본바와 같이 파일 에 로의 접 근은 그 파일 의 색 인마디 에 대 한 찾기 를 의 미한다. 
VFS 가 파일체계에서 이름을 어떻게 찾으며 어떻게 색인마디를 돌려 주는가를 보자. 

이 조작에 서는 경 로이 름의 시 작으로부터 출발하며 그 경 로안의 첫번째 등록부의 색 
인마디 를 검 색한다. 다음에 는 경 로안의 다음등록부를 찾는데 그 색 인마디 를 리용한다. 만 
일 끝에 도달하면 검 색하려 는 파일 이 나 등록부의 색 인마디 가 발견된 다. 조작을 계 속하려 
면 색인마디가 필요한데 그러면 첫번째 검색으로부터 어떻게 이 조작을 계속할것인가? 

파일 체 계 에 관한 색 인마디구조체 를 지 적하는 s_mounted 로 호출된 상위블로크안에 보 
존되 는 색 인마디지적 자가 있다. 이 색 인마디 는 파일체계 가 올려태 우기될 때 배 정되며 올 
려태 우기 가 해제 될 때 배 정해제된다. 보통 ext 2 파일체 계 에서처 럼 s_mounted 색 인마디 는 
파일체 계 뿌리 등록부의 색 인마디 이 다. 거 기 로부터 시 작하여 다른 모든 색 인마디 들을 검 색 
할수 있다. 

매 색 인마디는 함수에 대한 구조체지적자를 포함한다. 그것 이 바로 색 인마디 inode _ 
operations 구조체 이 다. 

이 구조체의 요소들중의 하나를 lookup () 이 라고 부르며 이것은 동일한 파일체계안에 
서 다른 색 인마디 들을 검 색하는데 리 용된 다. 

일 반적 으로 파일 체 계 는 그 파일 체 계안의 모든 색 인마디 에 곡 같은 한개 의 lookup () 함 
수만을 가지는데 이 것 으로 하여 여 러개의 서 로 다른 lookup () 함수들을 가지는것과 파일체 
계 에 적 합한 객체 로 그것을 지적할수 있다. proc 파일체 계는 파일체계안의 서 로 다른 등록 
부들이 서 로 다른 목적 을 가지 고 있기 때 문에 이 방법 을 리용할수 있 다. 

Inode_operations 구조체는 다음과 같다 (< linux / fs . h:^l 서 볼수 있는 거의 모든것과 류사 
하게 정의되 여 있다.). 

struct inode_operations { 

struct file_operations* default_file_ops; 

int (^create) (struct inode*, const char*, int, int, struct inode*); 

int (^lookup) (struct inode* , const char*, int, struct inode**); 
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int (*link) (struct inode*, struct inode*, const char*, int); 
int (*unlink) (struct inode*, const char*, int); 
int (*symlink) (struct inode*, const char*, int, const char*); 
int (*mkdir) (struct inode*, const char*, int, int); 

int (*rmdir) (struct inode*, const char*, int); 

int (*mknod) (struct inode*, const char*, int, int, int); 

int (^rename) (struct inode*, const char*, int, struct 
inode, const char *, int); 

int (*realink) (struct inode*, char*, int); 

int (*follow_link) (struct inode*, struct inode*, int, 

int, struct inode**); 

int (*readpage) (struct inode*, struct page*); 
int (*writepage) (struct inode*, struct page *); 
int (*bmap) (struct inode*, int); 
void (^truncate) (struct inode *); 
int (^permission)(struct inode*, int); 
int (*smap)(struct inode*, int); 

} 

이 대 다수의 기능들은 Linux 체계호출로 직접 적 으로 넘 겨 진다. ext 2 파일체계 에서 등 
록부，파일 그리 고 기 호련결들은 서 로 다른 inode_opemtions 를 가지 고 있 다. fs / ext 2/ dir.c 파일은 
exG _ dir _ inode 一 operations 를 포 함 하 며 fs / ext 2 /file 은 ext 2_ file _ inode_operations 를 포 함 하 며 
fs / ext 2/ symlink.c 는 ext 2_ symlink _ inode _ operations 를 포함한다. 

이 모든 파일들은 이 장의 마지막에 포함되여 있다. 

inode_operations 구조체 에 밝혀 지 지 않은 파일(등록부)과 관련된 체 계 호출도 많다. 그 
체 계 호출에 대 하여 서 는 file_operations 구조체 에 밝혀 져 있 다. file_operations 구조체 는 장치 
구동기 를 쓸 때 리용되 는 구조체 와 꼭 갈으며 색 인마디 보다도 파일 에 대 하여 작업하는 
조작들을 포함하고 있다. 


struct file_operations{ 

int (*lseek) (struct inode*, struct file*, off_t, int); 

int (*read) (struct inode*, struct file, char*, int) ; 

int (*write) (struct inode*, struct file*, const char*, int) ; 

int (*readdir) (struct inode*, struct file*, void *, filldir_t); 

int (*select) (struct inode*, struct file*, int, select_ table); 

int (*ioctl) (struct inode*, struct file*,unsigned int, nsigned long); 

int (*mmap) (struct inode*, struct file*, struct vm_area_struct); 

int (*open) (struct inode*, struct file*); 

void (^release) (struct inode 〜 struct file*); 

int (*fsync) (struct inode*, struct file*); 

int (*fasync) (struct inode*, struct file*, int); 

int (*check_media_change) (kdev_t dev) ; 
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int (^revalidate) (kdev_t dev); 

} ； 

체계호출과 직접적으로 관련되지 않은 몇개의 함수들도 있으며 그 함수들은 리용되 
지 는 않고 보통 NULL 로 설정되 여 있 다. 

원천과일 include / linux / fs . h (2.4.3) 



♦include <asm/atomic.h> 
♦include <asm/bitops.h> 
struct poll_table_struct; 
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S_SYNCHRONOUS | MS_MANDLOCK | MS_NOATIME | MS_NODIRATIME) 
































#define IS—APPEND(inode) ((inode)->i_flags & S—APPEND) 


#define IS_IMMUTABLE (inode) 
#define IS_NOATIME(inode) 


#define IS_NODIRATIME(inode) 


( (inode)->i_f lags & S_IMMUTABLE) 

( 一 IS_FLG(inode f MS_NOATIME) || ( (inode)- 
>i_flags & S_NOATIME) ) 

一 IS_FLG (inode, MS_NODIRATIME) 


#define IS_DEADDIR(inode) 


( (inode)->i_f lags & S_DEAD) 


* the read-only stuff doesn’t really belong here, but any other place is 
probably as bad and I don’t want to create yet another include file. */ 


#define BLKROSET _I0(0x12,93) 
#define BLKROGET _IO(Oxl2,94) 
#define BLKRRPART _IO(0x12,95) 
#define BLKGETSIZE _IO(Oxl2,96) 
#define BLKFLSBUF _IO(0x12,97) 
#define BLKRASET _IO(Oxl2 / 98) 
#define BLKRAGET 一 10(0x12,99) 
#define BLKFRASET _IO(0x12,100) 

#define BLKFRAGET —10(0x12,101) 

♦define BLKSECTSET —10(0x12,102) 

♦define BLKSECTGET _IO(0x12,103) 


/* set device read-only (0 = read-write) */ 
/* get read-only status (0 = ead_write) */ 
/* re-read partition table */ 

/* return device size */ 

/* flush buffer cache */ 

/* Set read ahead for block device */ 

/* get current read ahead setting */ 

/* set filesystem (mm/filemap.c) 
read-ahead */ 

/* get filesystem (iran/filemap.c) read- 
ahead */ 

/* set max sectors per request 
(ll_rw_blk.c) */ 

/* get max sectors per request 
(ll_rw_blk.c) */ 

♦define BLKSSZGET _IO(0x12,104) /* get block device sector size */ 

#if 0 

#define BLKPG _IO(0x12,105) /* See blkpg.h */ 

#define BLKELVGET _IOR(0xl2 f 106 f sizeof(blkelv_ioctl_arg_t))/* elevator get */ 
♦define BLKELVSET _IOW(0x12,107,sizeof(blkelv 一 ioctl_arg 一 t))/* elevator set */ 
/* This was here just to show that the number is taken 一 

probably all these _IO(Oxl2,*) ioctls should be moved to blkpg.h. */ 

#endif 


#define BMAP_IOCTL 1 

#define FIBMAP _IO(0x00,1) 

#define FIGETBSZ _IO(OxOO / 2) 


/* obsolete 一 1- 
/* bmap access */ 

/* get the block size used for bmap */ 
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#include <linux/mount.h> 



bd_count; 
































extern void — mark_inode_dirty (struct inode *, int) ; 
static inline void mark_inode_dirty(struct inode *inode) 
{ 


if ( (inode - >i_state & I_DIRTY) != I_DIRTY) 
__mark_inode_dirty (inode, I—DIRTY) ; 


static inline void mark_inode_dirty 一 sync(struct inode *inode) 

{ 

if (! (inode->i_state & I_DIRTY_SYNC) ) 


_mark_inode_dirty(inode, I_DIRTY_SYNC); 


static inline void mark_inode_dirty__pages(struct inode *inode) 

{ 


if (inode && ! (inode - 〉 i_state & I_DIRTY_PAGES) ) 
__mark_inode_dirty (inode, I_DIRTY_PAGES) ; 


struct fown_struct { 
int pid; 

uid_t uid, euid; 
int signum; 

}； 

struct file { 

struct list_head 
struct dentry 
struct vfsmount 


/* pid or -pgrp where SIGIO should be sent */ 
/* uid/euid of process setting the owner */ 

/* posix.lb rt signal to be delivered on 10 */ 


f_list; 

*f —dentry; 


struct file 一 operations 

atomic—t 

unsigned int 

mode_t 

loff_t 

unsigned long 
struct fown_struct 
unsigned int 


*f_op; 
f_count; 
f —flags; 
f_mode; 
f_pos; 

f_reada, f_ramax, f_raend f f_ralen, f_rawin; 

f_owner; 

f_uid, f_gid; 


int 
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unsigned char fl_type; 
loff_t fl_start; 
loff_t fl_end; 


void (*fl_notify)(struct file_lock *》; 
void (*fl_insert》(struct file_lock *) ; 


void (*fl_remove》(struct file_lock *) ; 


/* unblock callback */ 

/* lock insertion callback 

/* lock removal callback */ 


struct fasync—struct * fl_fasync; /* for lease break notifications V 


union { 

struct nfs_lock_info nfs_fl; 
} fl_u; 


/* The following constant reflects the upper bound of the file/locking 
space */ 

#ifndef OFFSET_MAX 

#define INT_LIMIT (x) 卜 ( (x) 1 « (sizeof (x) *8 -1))) 

#define OFFSET_MAX INT_LIMIT (loff_t) 

#define OFFT_OFFSET_MAX INT_LIMIT(off_t) 

#endif 

extern struct list_head file_lock_list; 

#include <linux/fcntl.h> 

extern int fcntl_getlk(unsigned int, struct flock *) ; 

extern int fcntl_setlk(unsigned int, unsigned int, struct flock ”; 

extern int fcntl_getlk64(unsigned int, struct flock64 *) ; 

extern int fcntl_setlk64(unsigned int, unsigned int, struct flock64 ; 


/* fs/locks.c */ 

extern void locks_init_lock(struct file_lock *) ; 

extern void locks_copy_lock(struct file_lock *, struct file_lock *) ; 
extern void locks_remove_posix (struct file *, fl_owner_t) ; 
extern void locks—remove 一 flock (struct file *); 
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time_t inode—expire [MAXQUOTAS]; 








































extern int vfs_unlink(struct inode 



* NOTE: 


readv, 

















loff_t (*llseek) (struct file *, loff_t, int); 

ssize_t (*read) (struct file *, char *, size 一 t, loff_t *) ; 

ssize_t (*write) (struct file *, const char *, size_t, loff_t *); 

int (*readdir) (struct file *, void *, filldir_t) ; 

unsigned int (*poll》(struct file *, struct poll_table_struct *) ; 

int (*ioctl) (struct inode *, struct file unsigned int, 
unsigned long); 

int (*mmap) (struct file *, struct vm_area_struct *) ; 
int (*open) (struct inode *, struct file ” ; 
int (*flush) (struct file *) ; 

int (^release) (struct inode *, struct file *); 

int (*fsync) (struct file *, struct dentry *, int datasync); 

int (*fasync) (int, struct file int); 

int (*lock) (struct file *, int, struct file_lock *); 

ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, 

loff_t 

ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, 
loff_t *); 


struct inode_operations { 

int (^create) (struct inode *,struct dentry *,int); 
struct dentry * (*lookup) (struct inode *,struct dentry *); 
int (*link) (struct dentry *, struct inode *,struct dentry *); 
int (*unlink) (struct inode struct dentry *); 
int (*symlink) (struct inode *, struct dentry * f const char *); 
int (*mkdir) (struct inode *, struct dentry *,int); 
int (*rmdir) (struct inode *, struct dentry *); 
int (*mknod) (struct inode *,struct dentry *, int,int); 
int (*rename) (struct inode *, struct dentry *, 
struct inode *, struct dentry *); 
int (*readlink) (struct dentry *, char *,int); 
int (*follow_link) (struct dentry *, struct nameidata *); 
void (^truncate) (struct inode *) ; 
int (^permission) (struct inode *, int) ; 
int (*revalidate) (struct dentry *) ; 
int (*setattr) (struct dentry *, struct iattr *); 
int (*getattr) (struct dentry struct iattr *); 


}； 
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* NOTE : write—inode, delete—inode, clear—inode, put_inode can be called 

* without the big kernel lock held in all filesystems. 

struct super_operations { 

void (*read_inode) (struct inode ” ; 

void (*write_inode) (struct inode *, int) ; 

void (*put_inode) (struct inode *); 

void (*delete_inode) (struct inode ” ; 

void (*put_super) (struct super—block *) ; 

void (*write_super 》 (struct super—block *); 

int (*statfs) (struct super—block *, struct statfs *); 

int (*remount_fs) (struct super—block *, int *, char *) ; 

void (*clear 一 inode) (struct inode *) ; 

void (*umount_begin) (struct super—block *) ; 


struct dquot_operations { 

void (^initialize) (struct inode *, short); 
void (*drop) (struct inode ” ; 

int (*alloc_block) (const struct inode *, unsigned long, char); 

int (*alloc_inode) (const struct inode *, unsigned long); 

void (*free_block) (const struct inode *, unsigned long); 

void (*free 一 inode) (const struct inode *, unsigned long); 

int (^transfer) (struct dentry *, struct iattr *) ; 


struct file_system_type { 
const char *name; 
int fs_flags; 

struct super—block * (*read_super) (struct super—block *, void *, int》; 
struct module *owner; 

struct vfsmount *kern_mnt; /* For kernel mount , if it 1 s FS_SINGLE fs * 
struct file_system_type * next; 


#define DECLARE—FSTYPE(var,type,read,flags) \ 
struct file_system_type var = { \ 









name : type, \ 

read_super: read, \ 
fs_flags : flags, \ 

owner : THIS—MODULE, \ 

} 

#define DECLARE 一 FSTYPE—DEV(var,type, read) \ 

DECLARE 一 FSTYPE (var, type, read, FS_REQUIRES_DEV) 

/* Alas, no aliases. Too much hassle with bringing module.h everywhere */ 
#define fops_get(fops) \ 

(((fops) && (fops) - >owner) \ 

? ( try_inc_mod_count ( (fops) - >owner) ? (fops) : NULL ) \ 

: (fops)) 

#define fops_put(fops) \ 
do { \ 

if ((fops) && (fops) - >owner) \ 

— MOD_DEC_USE_COUNT((fops) - >owner); \ 

} while(0) 

extern int register_filesystem(struct file_system_type *); 
extern int unregister 一 filesystem(struct file_system_type *); 
extern struct vfsmount *kern_mount(struct fi1e_system_type *) ; 
extern void kern_umount(struct vfsmount *) ; 
extern int may_umount (struct vf smount *) ; 

extern long do_mount (char *, char *, char *, unsigned long, void *); 

extern int vfs_statfs(struct super—block *, struct statfs *); 

/* Return value for VFS lock functions - tells locks.c to lock conventionally 
* REALLY kosha for root NFS and nfs 一 lock 
*/ 

#define LOCK_USE_CLNT 1 


#define FLOCK_VERIFY_READ 1 
#define FLOCK_VERIFY_WRITE 2 

extern int locks 一 mandatory_locked(struct inode *); 
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} 


return 0; 


extern inline int get_lease(struct inode *inode A unsigned int mode) 

{ 

if (inode->i_flock && (inode - 〉 i_flock - >fl_flags & FL_LEASE) ) 

return_get_lease (inode, mode) ; 

return 0; 

} 

/* fs/open.c */ 

asmlinkage long sys_open (const char *, int, int) ; 

asmlinkage long sys_close(unsigned int); /* yes, it 1 s really unsigned */ 

extern int do_truncate(struct dentry loff_t start); 

extern struct file *filp 一 open (const char int f int); 

extern struct file * dentry 一 open(struct dentry *, struct vfsmount *, int); 
extern int filp_close (struct file *, f l_owner_t id); 
extern char * get name (const char *); 


/* fs/dcache.c */ 

extern void vfs_caches_init(unsigned long); 

#def ine get name () kmem_cache_alloc (names—cachep, SLAB_KERNEL) 

#define put name (name) kmem_cache_free (names 一 cachep, (void *) (name) ) 


enum {BDEV—FILE, BDEV_SWAP, BDEV—FS, BDEV_RAW}; 

extern int register_blkdev(unsigned int, const char *, struct 

block_device_operat ions *) ; 

extern int unregister_blkdev(unsigned int, const char *) ; 

extern struct block_device *bdget(dev_t); 

extern void bdput (struct block 一 device *) ; 

extern int blkdev_open(struct inode *, struct file *) ; 

extern struct file_operations def_b 1k_fops; 

extern struct file_operations def_fifo_fops; 

extern int ioctl_by_bdev(struct block—device unsigned, unsigned long); 
extern int blkdev_get (struct block—device *, mode_t, unsigned, int); 
extern int blkdev_put(struct block—device *, int) ; 
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/* fs/devices.c */ 

extern const struct block_device_operations *get_blkfops(unsigned int) ; 
extern int register_chrdev(unsigned int, const char *, struct 
file_operations *) ; 

extern int unregister_chrdev(unsigned int, const char *) ; 
extern int chrdev_open(struct inode *, struct file *); 
extern const char * bdevname(kdev_t); 
extern const char * cdevname(kdev_t); 
extern const char * kdevname(kdev_t); 

extern void init_special_inode (struct inode *, umode_t, int) ; 


/* Invalid inode operations -- fs/bad_inode.c */ 
extern void make_bad_inode(struct inode *) ; 
extern int is_bad_inode(struct inode *); 


extern struct 
extern struct 
extern struct 
extern struct 
extern struct 
extern struct 


file_operations 
file_operations 
file_operations 
file_operations 
file_operations 
file_operations 


read_fif o_fops; 
write_f ifo 一 fops; 
rdwr_f i f o_f ops; 
read_ ， pipe_f ops; 
write_pipe_f ops; 
rdwr__pipe_fops; 


extern int i 


: super 一 block *) ; 


extern int try_to_free 一 buffers (struct page *, int) ; 
extern void refile_buffer(struct buffer_head * buf); 
#define BUF—CLEAN 0 


♦define BUF_LOCKED 


1 /* Buffers scheduled for write */ 


#define BUF—DIRTY 2 /* Dirty buffers, not yet scheduled for write */ 

♦define BUF—PROTECTED 3 /* Ramdisk persistent storage */ 

♦define NR_LIST 4 


* This is called by bh - 〉 b_end_io () handlers when I/O has completed. 

static inline void mark_buffer_uptodate (struct buffer_head * bh, int on) 

{ 

if (on) 

set_bit(BH_Uptodate, &bh->b_state); 
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extern void sync_supers(kdev_t); 
extern int bmap(struct inode *, int) ; 

extern int notify_change(struct dentry struct iattr *); 

extern int permission (struct inode int) ; 

extern int vfs_permission (struct inode int) ; 

extern int get_write_access(struct inode *); 

extern int deny_write_access (struct file *); 

static inline void put_write_access (struct inode * inode) 

{ 

atomic 一 dec( & inode->i_writecount); 

} 

static inline void allow_write_access(struct file *file) 

{ 

if (file) 

atomic_inc(&file->f_dentry->d_inode->i_writecount); 

} 

extern int do_pipe (int *); 

extern int open_namei (const char *, int, int, struct nameidata *) ; 

extern int kernel_read(struct file *, unsigned long, char *, unsigned long); 
extern struct file * open_exec (const char ” ; 

/* fs/dcache.c -一 generic fs support functions */ 

extern int is_subdir(struct dentry *, struct dentry *) ; 

extern 丄 no_t find_inode_number(struct dentry *, struct qstr *) ; 


Kernel pointers have redundant information, so we can use a 
scheme where we can return either an error code or a dentry 
pointer with the same return value. 


* This should be a per-architecture thing, to allow different 

* error and pointer decisions. 

static inline void *ERR_PTR(long error) 

{ 

return (void *) error; 
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} 


static inline long PTR—ERR(const void *ptr) 

{ 

return (long) ptr; 

} 

static inline long IS 一 ERR(const void *ptr) 

{ 

return (unsigned long)ptr > (unsigned long)-1000L; 

} 

* The bitmask for a lookup event : 

* - follow links at the end 

* - require a directory 

* - ending slashes ok even for nonexistent files 

* - internal "there are more path components” flag 


#define LOOKUP_FOLLOW (1) 

#define LOOKUP-DIRECTORY (2) 

#define LOOKUP_CONTINUE (4) 

#define LOOKUP-POSITIVE (8) 

#define LOOKUP-PARENT (16) 

♦define LOOKUP_NOALT (32) 


* Type of the last component on LOOKUP_PARENT 

enum {LAST_NORM, LAST_ROOT f LAST_DOT, LAST_DOTDOT, LAST_BIND}; 

* "descriptor 11 for what we' re up to with a read for sendfile () . 

* This allows us to use the same read code yet 

* have multiple different users of the data that 

* we read from a file. 

* The simplest case just copies the data to user 

* mode. 

*/ 
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static inline struct inode * new 一 inode(struct super 一 block *sb) 

{ 

struct inode *inode = get_empty_inode(); 
if (inode) { 

inode->i_sb = sb; 
inode->i_dev = sb - >s_dev; 

} 

return inode; 

} 


extern void insert_inode_hash(struct inode *); 
extern void remove_inode_hash (struct inode *); 
extern struct file * get_empty_filp (void) ; 

extern void file_move(struct file *f, struct list_head *list); 

extern void file 一 moveto(struct file *new, struct file *old); 

extern struct buffer_head * get_hash_table(kdev_t, int, int) ; 

extern struct buffer_head * getblk(kdev_t, int, int) ; 

extern void ll_rw_block(int, int, struct buffer_head * bh[]); 

extern void submit_bh (int, struct buffer_head ” ; 

extern int is_read_only(kdev_t); 

extern void _brelse (struct buffer_head ” ; 

static inline void brelse(struct buffer_head *buf) 

( 

if (buf) 

— brelse(buf); 

} 

extern void — bforget (struct buffer_head *) ; 
static inline void bforget(struct buffer_head *buf) 

{ 

if (buf) 

— bforget(buf); 

} 

extern void set_blocksize(kdev_t f int) ; 
extern unsigned int get_hardblocksize(kdev_t); 
extern struct buffer_head * bread(kdev_t, int, int〉; 
extern void wakeup_bdflush(int wait); 

extern int brw_page (int, struct page kdev_t, int [], int) ; 
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typedef int (get_block_t)(struct inode*,long,struct buffer_head*,int); 


/* Generic buffer handling for block filesystems.. */ 
extern int block_flushpage(struct page unsigned long); 
extern int block_syml ink (struct inode *, const char *, int); 
extern int block_write_full_page (struct page*, get_block_t*》; 
extern int block_read_full_page(struct page*, get_block 一 t*); 
extern int block_ ， prepare_write(struct page*, unsigned, unsigned, 
get_block_t*) ; 

extern int cont_prepare_write(struct page*, unsigned, unsigned, get_block_t* f 
unsigned long *) ; 
extern int block_sync_page (struct page *); 

int generic_block_bmap(struct address—space *, long, get_block_t *); 

int generic_commit_write (struct file struct page *, unsigned, unsigned) ; 

int block 一 truncate_，page (struct address—space *, loff_t, get_block_t ” ; 

extern int generic_file_mmap (struct file struct vm_area_struct *) ; 
extern ssize_t generic_file_read(struct file *, char *, size_t, loff_t *) ; 
extern ssize_t generic_file_write (struct file *, const char *, size_t, loff_t 
”; 

extern void do_generic_file_read(struct file *, loff_t *, read_descriptor_t 
read_act or_t); 

extern ssize_t generic_read_dir (struct file *, char *, size_t, loff_t *) ; 


extern struct file_operations gener 丄 c_ro_fops; 


extern int vfs_readlink (struct dentry *, char *, int, const char *); 
extern int vfs_follow_l 丄 nk(struct nameidata *, const char *) ; 
extern int page_readlink (struct dentry *, char int) ; 
extern int page_follow_link(struct dentry *, struct nameidata *) ; 
extern struct inode_operations page_symlink_inode_operations; 

extern int vfs_readdir (struct file *, filldir_t, void *) ; 
extern int dcache_readd 丄 r (struct file *, void *, filldir_t) ; 


extern struct file_system_type *get_fs_type(const char *name); 
extern struct super_block *get_super(kdev_t); 












struct super_block *get_empty_super(void); 
extern void put_super (kdev_t) ; 

unsigned long generate—cluster (kdev_t, int b[], int) ; 
unsigned long generate_cluster_swab32 (kdev_t f int b[], int); 
extern kdev_t ROOT—DEV; 
extern char root_device_name [ ] ; 

extern void show_buffers(void) ; 
extern void mount_root (void) ; 

#ifdef CONFIG_BLK_DEV_INITRD 
extern kdev_t real_root_dev; 
extern int change_root(kdev_t, const char *) ; 

#endif 

extern ssize_t char_read(struct file *, char size 一 t, loff_t *); 

extern ssize_t block_read(struct file *, char *, size_t, loff 一 t ” ; 
extern int read_ahead[]; 

extern ssize_t char_write (struct file const char size_t, loff_t *》; 
extern ssize_t block_write(struct file const char size_t, loff_t *) 

extern int file_fsync(struct file *, struct dentry int) ; 

extern int generic 一 buffer_fdatasync(struct inode *inode, unsigned long 

start_idx, unsigned long end 一 idx); 

extern int generic 一 osync 一 inode (struct inode *, int); 

extern int 丄 node_change_ok(struct inode *, struct iattr *) ; 
extern void inode—setattr(struct inode *, struct iattr *); 


/* 

* Common dentry functions for inclusion in the VFS 

* or in other stackable file systems. Some of these 

* functions were in linux/fs/ C (VFS) files. 


*/ 


Locking the parent is needed to: 

- serialize directory operations 
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* 一 make sure the parent doesn’t change from 

* under us in the middle of an operation. 

* NOTE! Right now we f d rather use a ,f struct inode 1 ' 

* for this, but as I expect things to move toward 

* using dentries instead for most things it is 

* probably better to start with the conceptually 

* better interface of relying on a path of dentries. 

static inline struct dentry *lock_parent(struct dentry *dentry) 

{ 

struct dentry *dir = dget(dentry->d_parent); 

down (&dir->d_inode->i_sem) ; 
return dir; 

} 

static inline struct dentry *get_parent(struct dentry *dentry) 

{ 

return dget(dentry->d_parent); 

} 

static inline void unlock_dir(struct dentry *dir) 

{ 

up (&dir - 〉 d_inode - 〉 i_sem) ; 



/* 

* Whee.. Deadlock country. Happily there are only two VFS 

* operations that does this.. 

*/ 

static inline void double_down(struct semaphore *sl, struct semaphore *s2) 

{ 

if (si != s2) { 

if ( (unsigned long) si < (unsigned long) s2) { 
struct semaphore *tmp = s2; 
s2 = si; si = tmp; 


} 
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#endif /* _Linux_FS_H */ 

원천파일 fs/ext2/super.c(2.4.( 

* linux/fs/ext2/super.c 

* Copyright (C) 1992, 1993, 1994, ] 

* Remy Card (card@masi.ibp.fr) 

* Laboratoire MASI - Institut Blaii 

* Universite Pierre et Marie Curie 

* 

* from 

* linux/fs/minix/inode.c 

* Copyright (C) 1991, 1992 Linus 

* 

* Big-endian to little-endian byte 

* David S. Miller (davem@caii 

#include <linux/config.h> 

#include <linux/module.h> 

#include <linux/string.h> 

#include <linux/fs.h> 

#include <linux/ext2_fs.h> 

#include <linux/slab.h> 

#include <linux/init.h> 

#include <linux/locks.h> 

#include <asm/uaccess.h> 

static char error_buf [ 1024]; 

void ext2_error (struct super_block 
const char * fmt, . . .) 

{ 

va_list args; 
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if ( ! (sb->s_flags & MS_RDONLY) ) { 

sb->u.ext2_sb.s_mount_state | = EXT2_ERR0R_FS; 
sb->u.ext2_sb.s_es->s_state = 

cpu_to_lel6 (lel6_to_cpu (sb->u. ext2_sb. s_es->s_state) | 

EXT2_ERR0R_FS); 

mark_buffer_dirty(sb->u.ext2 一 sb.s_sbh); 
sb->s_dirt = 1; 

} 

va_start (args, fmt); 
vsprintf (error_buf, fmt, args); 
va_end (args) ; 

if (test_opt (sb, ERRORS_PANIC) | | 

(lel6_to_cpu(sb->u.ext2_sb.s_es->s_errors) == EXT 2_ERR0RS_PANIC 

&& 

! test_opt (sb, ERRORS_CONT) && ! test_opt (sb, ERRORS_RO) ) ) 
panic (” EXT2 — fs panic (device %s) : %s : %s\n n , 

bdevname(sb->s_dev), function, error_buf); 
printk (KERN_CRIT ,f EXT2-fs error (device %s) : %s: %s\n n , 
bdevname(sb->s_dev), function, error_buf); 
if (test_opt (sb, ERRORS_RO) | | 

(lei6_to_cpu (sb->u. ext2_sb. s_es->s_errors) == EXT2_ERR0RS_R0 && 
!test_opt (sb, ERRORS_CONT) && !test_opt (sb, ERRORS_PANIC) ) ) { 
printk ("Remounting filesystem read-only\n"); 
sb->s_flags |= MS_RDONLY; 


NORET—TYPE void ext2_panic (struct super_block * sb, const char 
function. 


const char * fmt f 


va_list args; 


if ( ! (sb->s_flags & MS_RDONLY)) { 

sb->u . ext2_sb. s_mount_state | = EXT2_ERR0R_FS; 
sb->u.ext2_sb.s_es->s_state = 

cpu_to_lel6(lel6_to_cpu(sb->u.ext2_sb.s_es->s_state) | 


EXT2_ERR0R_FS); 
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mark_buffer_dirty(sb->u.ext2_sb.s_sbh); 
sb->s_dirt = 1; 

} 

va_start (args, fmt); 
vsprintf (error_buf, fmt, args); 
va_end (args); 

/* this is to prevent panic from syncing this filesystem */ 
if (sb->s_lock) 

sb->s_lock=0; 
sb->s_flags |= MS_RDONLY; 

panic ( ,f EXT2-fs panic (device %s) : %s : %s\n n , 

bdevname(sb->s_dev), function, error_buf); 


void ext2_warning (struct super_block ■ 
const char * fmt, . . .) 

{ 

va_list args; 


sb, const char * function. 


va_start (args, fmt); 
vsprintf (error_buf, fmt, args); 
va_end (args) ; 

printk (KERN_WARNING ,f EXT2-f s warning (device %s) : %s : %s\n”, 
bdevname(sb - >s_dev》, function, error_buf); 

} 

void ext2_update_dynamic_rev(struct super_block *sb) 

{ 

struct ext2_super_block *es = EXT2_SB(sb) - >s_es; 


if (le32_to_cpu (es->s_rev_level) > EXT2_G00D_0LD_REV) 
return; 


ext2 一 warning (sb, FUNCTION , 

’’updating to rev %d because of new feature flag, 
,f running e2fsck is recommended”, 
EXT2_DYNAMIC_REV) ; 


es->s_first_ino = cpu_to_le32 (EXT2_G00D_0LD_FIRST_INO) ; 
es->s_inode_size = cpu_to_lel6 (EXT2_G00D_0LD_IN0DE_SIZE) ; 
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printk ( f, EXT2 Check option not supported\n f, ) ; 













} 


} 

/* Silently ignore the quota options */ 
else if (! strcmp (this_char, ,f grpquota ,f ) 

|| ! strcmp (this_char, ’’noquota ’’》 

I | ! strcmp (this_char, ’’quota ’’》 

|| ! strcmp (this_char, ,f usrquota ,f ) ) 

/* Don’t do anything ;-) */ ; 

else { 

printk ("EXT2-fs: Unrecognized mount option %s\n”, this_char); 
return 0; 


return 1; 


static int ext2_setup_super (struct super—block * sb, 
struct ext2_super_block * es r 
int read_only) 

{ 

int res = 0; 

if (le32_to_cpu (es->s_rev_level) > EXT2_MAX_SUPP_REV) { 

printk ( ,f EXT2-f s warning : revision level too high, ,f 
"forcing read-only mode\n"); 
res = MS_RDONLY; 

} 

if (read_only) 

return res; 

if (!(sb->u.ext2_sb.s_mount_state & EXT2_VALID_FS)) 

printk (”EXT2-fs warning : mounting unchecked fs, ” 
"running e2f sck is recommended\n f, ) ; 
else if ( (sb->u . ext2_sb. s_mount_state & EXT2_ERROR_FS) ) 

printk (”EXT2-fs warning : mounting fs with errors, ” 
"running e2f sck is recommended\n f, ) ; 

else if ( (_sl6) lei6_to_cpu (es->s_max_mnt_count) >= 0 && 

lel6_to_cpu (es->s_mnt_count) >= 

(unsigned short) (_sl6) lel6_to_cpu (es->s_max_mnt_count) ) 

printk (’’EXT2 - fs warning : maximal mount count reached, ,f 
"running e2f sck is recommended\n f, ) ; 
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else if (le32_to_cpu (es->s_checkinterval) && 

(le32_to_cpu (es->s_lastcheck) + le32_to_cpu (es- 
>s_checkinterval) <= CURRENT_TIME)) 

printk ( ,f EXT2-f s warning : checktime reached, ,f 
"running e2fsck is recommended\n n ); 
es->s_state = cpu_to_lel6 (lel6_to_cpu (es->s_state) & -EXT2 
_VALID_FS); 

if (!(_sl6) lel6_to_cpu (es->s_max_mnt_count) ) 

es->s_max_mnt_count = (_sl6) cpu_to_lel6 (EXT2_DFL_MAX 

_MNT_COUNT) ; 

es->s_mnt_count=cpu_to_lel6 (lel6_to_cpu (es->s_mnt_count) +) ; 

es->s_mtime = cpu_to_le32(CURRENT_TIME); 

mark_buffer_dirty(sb- 〉 u.ext2_sb.s_sbh); 

sb->s_dirt = 1; 

if (test_opt (sb, DEBUG) ) 

printk ( ,f [EXT II FS %s, %s, bs=%lu, fs=%lu, gc=%lu, " 
"bpg=%lu, ipg=%lu, mo=%041x] \n f, f 
EXT2FS_VERSI0N, EXT2FS_DATE, sb- 〉 s_blocksize, 
sb->u.ext2_sb.s_frag_size, 
sb->u.ext2_sb.s_groups_count, 
EXT2_BL0CKS_PER_GR0UP(sb) f 
EXT2_IN0DES_PER_GR0UP(sb) f 
sb->u. ext2_sb. s_mount_opt) ; 

#ifdef C0NFIG_EXT2_CHECK 

if (test_opt (sb, CHECK) ) { 

ext2_check_blocks_bitmap (sb) ; 
ext2_check_inodes_bitmap (sb) ; 

} 

#endif 

return res; 

} 


static int ext2_check_descriptors (struct super_block * sb) 

{ 

int i; 

int desc_block = 0; 

unsigned long block = le32_to_cpu(sb->u.ext2_sb.s_es- 

>s_f irst_data_block) ; 

struct ext2_group_desc * gdp = NULL; 
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ext2_debug ( ,f Checking group descriptors’’); 


for (i = 0; i < sb->u. ext2_sb. s_groups_count; i++) 

{ 

if ( (i % EXT2_DESC_PER_BLOCK(sb) ) == 0) 
gdp = (struct ext2_group_desc *) sb- 
>u . ext2_sb. s_group_desc [desc_block++] - >b_data; 
if (le32_to_cpu (gdp->bg_block_bitmap) < block | | 
le32_to_cpu(gdp->bg_block_bitmap) >= block + 
EXT2_BLOCKS_PER_GROUP(sb)) 

{ 

ext2_error (sb, ”ext2_check_descriptors”, 
’’Block bitmap for group %d" 

’’ not in group (block %lu) ! n , 

i,(unsigned long) le32_to_cpu(gdp- 
>bg_block_bitmap) ) ; 
return 0; 

} 

if (le32_to_cpu (gdp->bg_inode_bitmap) < block | | 

le32_to_cpu(gdp->bg_inode_bitmap) >= block + 
EXT2_BLOCKS_PER_GROUP (sb) ) 

{ 

ext2_error (sb, "ext2_check_descriptors f, f 
’’Inode bitmap for group %d ,f 
’’ not in group (block %lu) ! n , 
i, (unsigned long) le32_to_cpu(gdp - 
>bg_inode_bitmap)); 
return 0; 

} 

if (le32_to_cpu (gdp->bg_inode_table) < block | | 
le32_to_cpu (gdp- 〉 bg_inode_table) + sb- 
>u.ext2_sb.s_itb_per_group >= 
block + EXT2_BLOCKS_PER_GROUP (sb) ) 

{ 

ext2_error (sb, n ext2_check_descriptors n , 

’’Inode table for group %d” 

’’ not in group (block %lu) ! n , 

i, (unsigned long) le32_to_cpu(gdp- 














"unsupported optional features (%x 》 .\n”, 
bdevname(dev), i) ; 
goto failed_mount; 

} 

sb->s_blocksize_bits = 

le32_to_cpu (EXT2_SB (sb) - >s_es->s_log_block_size) + 10; 
sb->s_blocksize = 1 << sb->s_blocksize_bits; 
sb->s_maxbytes = ext2_max_size(sb->s_blocksize_bits); 

if (sb->s_blocksize != blocksize && 

(sb->s_blocksize == 1024 | | sb->s_blocksize == 2048 | | 
sb->s_blocksize == 4096)) { 

* Make sure the blocksize for the filesystem is larger 

* than the hardware sectorsize for the machine. 

if (sb->s_blocksize < hblock) { 

printk ( ,f EXT2-f s : blocksize too small for device . \n ,f ) ; 
goto failed_mount; 


brelse (bh); 

set_blocksize (dev, sb->s_blocksize); 


(sb_block*BLOCK 一 SIZE) / sb->s_blocksize; 


offset = (sb_block*BLOCK_SIZE) % sb->s_blocksize; 


bh = bread (dev, logic_sb_block, sb->s_blocksize); 
if(!bh) { 

printk ( f, EXT2-f s : Couldn’t read superblock on 
f, 2nd try.\n n ) ; 
goto failed—mount; 


} 

es=(struct ext2_super_block *) (((char *)bh - 〉 b_data)+offset); 
sb->u.ext2_sb.s_es = es; 

if (es->s_magic != lel6_to_cpu(EXT2_SUPER_MAGIC)) { 
printk ( ,f EXT2-f s : Magic mismatch, very weird ! \n ,f ) ; 
goto failed—mount; 


} 
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if (le32_to_cpu (es->s_rev_level) == EXT2_G00D_0LD_REV) { 

sb->u.ext2_sb. s_inode_size = EXT2_G00D_0LD_IN0DE_SIZE; 
sb->u . ext2_sb . s_f irst_ino = EXT2_G00D_0LD_FIRST_INO; 

} else { 

sb- 〉 u.ext2_sb.s_inode_size = lel6_to_cpu(es->s_inode_size); 
sb->u.ext2_sb.s_first_ino = le32_to_cpu(es->s_first_ino); 
if (sb->u. ext2_sb. s_inode_size != EXT2_GOOD_OLD_INODE_SI ZE) 

{ 

printk ( f, EXT2-f s : unsupported inode size : %d\n f, , 
sb->u . ext2_sb. s_inode 一 size) ; 
goto failed_mount; 

} 

} 

sb->u . ext2_sb. s_f rag_size = EXT2_MIN_FRAG_S I ZE << 

le32_to_cpu (es->s_log_f rag_size) ; 
if (sb->u.ext2_sb.s_frag_size) 

sb->u.ext2_sb.s_frags_per_block = sb->s_blocksize / 
sb - 〉 u.ext2_sb.s_frag_size; 

else 

sb->s_magic = 0; 

sb->u.ext2_sb.s_blocks_per_group = le32_to_cpu(es->s_blocks_ 
per_group); 

sb->u.ext2_sb.s_frags_per_group = le32_to_cpu(es->s_f rags_ 
per_group); 

sb->u.ext2_sb.s_inodes_per_group = le32_to_cpu(es->s_inodes_ 
per_group); 

sb->u.ext2_sb.s_inodes_per_block = sb - >s_blocksize / 
EXT2_INODE_SIZE(sb〉; 

sb - 〉 u. ext2_sb. s_itb_ ， per_group=sb- 〉 u. ext2_sb. s_inodes_per_group / 
sb - 〉 u.ext2_sb.s_inode s_pe r_b1o ck; 
sb->u.ext2_sb.s_desc_per_block = sb->s_blocksize / 

sizeof (struct ext2_group_desc); 
sb->u. ext2_sb. s_sbh = bh; 
if (resuid != EXT2_DEF_RESUID) 

sb- 〉 u.ext2_sb.s_resuid = resuid; 

else 

sb - >u.ext2_sb. s_resuid = lel6_to_cpu (es->s_def_resuid) ; 
if (resgid != EXT2_DEF_RESGID) 

sb->u.ext2_sb.s_resgid = resgid; 
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sb->u. ext2_sb. s_resgid = lel6_to_cpu (es->s_def_resgid) ; 
sb->u.ext2_sb.s_mount_state = lel6_to_cpu(es->s_state); 
sb->u.ext2_sb.s_addr_pe r_b1o ck_bits = 
log2 (EXT2_ADDR_PER_BL0CK(sb)); 
sb->u.ext2_sb.s_de s c_pe r_b1o ck_bits = 
log2 (EXT2_DESC_PER_BL0CK(sb)) ; 
if (sb->s_magic != EXT2_SUPER_MAGIC) { 
if (!silent) 

printk (”VFS: Can 1 1 find an ext2 filesystem on dev 
n %s.\n，，, 
bdevname(dev)); 
goto failed_mount; 

} 

if (sb->s_blocksize ! = bh->b_size) { 
if (!silent) 

printk ( f, VFS : Unsupported blocksize on dev ” 
n %s.\n”, bdevname(dev)); 
goto failed_mount; 


if (sb->s_blocksize != sb->u.ext2_sb.s_frag_size) { 
printk ( ,f EXT2-f s : f ragsize %lu != blocksize %lu (not 
supported yet)\n ”, 

sb- 〉 u.ext2_sb.s_frag_size, sb->s_blocksize); 
goto failed_mount; 


if (sb->u. ext2_sb. s_blocks_per_group > sb->s_blocksize * 8) 
printk ( ,f EXT2-fs : #blocks per group too big: %lu\n”, 
sb->u.ext2_sb.s_blocks_per_group); 
goto failed_mount; 

} 

if (sb->u. ext2_sb. s_f rags_per_group > sb - >s_blocksize * 8) 
printk ( ,f EXT2-f s : #fragments per group too big : %lu\n”, 
sb->u.ext2_sb.s_f rags_per_group); 
goto failed_mount; 


if (sb->u. ext2_sb. s_inodes_per_group > sb - >s_blocksize * 8) 














} 

sb->u . ext2_sb. s_loaded_inode_bitmaps = 0; 
sb->u . ext2_sb. s_loaded_block_bitmaps = 0; 
sb->u . ext2_sb. s_gdb_count = db_count ; 

* set up enough so that it can read an inode 
*/ 

sb->s_op = &ext2 一 sops; 

sb->s_root = d_alloc_root(iget(sb, EXT2_ROOT_INO)); 
if (!sb - >s_root 》 { 

for (i = 0; i < db_count; i++) 

if (sb - 〉 u. ext2_sb. s_group_desc [i] ) 

brelse (sb->u.ext2_sb.s_group_desc[i]); 
kfree(sb->u.ext2_sb.s_group_de s c); 
brelse (bh); 

printk (”EXT2-fs: get root inode f ailed\n ,f ) ; 
return NULL; 

} 

ext2_setup_super (sb, es, sb->s_flags & MS_RDONLY) ; 
return sb; 


static void ext2_commit_super (struct super—block * sb, 
struct ext2_super_block * es) 

{ 

es->s_wtime = cpu_to_le32 (CURRENT_TIME) ; 
mark_buffer_dirty(sb->u.ext2_sb.s_sbh); 
sb->s_dirt = 0; 


In the second extended file system, it is not necessary to 
write the super block since we use a mapping of the 
disk super block in a buffer. 


* However, this function is still used to set the fs valid 

* flags to 0. We need to set this flag to 0 since the fs 
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* may have been checked while mounted and e2fsck may have 

* set s_state to EXT2_VALID_FS after some corrections. 

void ext2_write_super (struct super_block * sb) 

{ 

struct ext2_super_block * es; 

if ( ! (sb - >s_flags & MS_RDONLY) ) { 
es = sb->u. ext2_sb. s_es; 

ext2_debug (’’setting valid to 0\n ,f ) ; 

•f (lel6_to_cpu (es->s_state) & EXT2_VALID_FS) { 
es->s_state = cpu_to_lel6(lel6_to_cpu(es->s_state) & 
〜 EXT2_VALID_FS); 

es- 〉 s_mtime = cpu_to_le32(CURRENT_TIME); 

} 

ext2_commit_super (sb, es) ; 

} 

sb->s_dirt = 0; 


int ext2_remount (struct super_block * sb, int * flags, char * data) 

{ 

struct ext2_super_block * es; 

unsigned short resuid = sb- 〉 u.ext2_sb.s_resuid; 
unsigned short resgid = sb->u.ext2_sb.s_resgid; 
unsigned long new_mount_opt; 
unsigned long tmp; 

* Allow the "check" option to be passed as a remount option. 
new_mount_opt = sb->u.ext2_sb.s_mount_opt; 

if (!parse_options (data, &tmp, &resuid, &resgid, &new_mount_opt)) 
return -EINVAL; 

sb->u.ext2_sb.s_mount_opt = new_mount_opt; 
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sb->u.ext2_sb.s_resuid = resuid; 
sb->u.ext2_sb.s_resgid = resgid; 
es = sb - >u. ext2_sb. s_es; 

if ((*flags & MS_RDONLY) == (sb->s_flags & MS_RDONLY) ) 
return 0; 

if (*flags & MS_RDONLY) { 

if (lel6_to_cpu (es->s_state) & EXT2_VALID_FS || 

! (sb->u.ext2_sb. s_mount_state & EXT2_VALID_FS) ) 
return 0; 

* OK, we are remounting a valid rw partition rdonly, so set 

* the rdonly flag and then mark the partition as valid again. 

es->s_state = cpu_to_lel6 (sb->u. ext2_sb. s_mount_state) ; 
es - >s_mtime = cpu_to_le32(CURRENT_TIME); 
mark_buffer_dirty(sb->u.ext2_sb.s_sbh); 
sb->s_dirt = 1; 
ext2_commit_super (sb, es) ; 

} 

else { 

int ret; 

if ( (ret = EXT2_HAS_RO_COMPAT_FEATURE (sb, EXT2_FEATURE_ 
RO_COMPAT_SUPP) ) ) { 

printk(”EXT2 - fs: %s : couldn’t remount RDWR because of " 
"unsupported optional features (%x).\n 
bdevname(sb->s_dev), ret) ; 
return -EROFS; 

} 

* Mounting a RDONLY partition read - write, so reread and 

* store the current valid flag. (It may have been changed 

* by e2fsck since we originally mounted the partition.) 

sb->u.ext2_sb.s_mount_state = lel6_to_cpu(es->s_state); 
if (! ext2_setup_super (sb, es, 0) ) 
sb - 〉 s_flags &= -MS_RDONLY; 

} 

return 0; 
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- overhead; 

buf->f_bfree = ext2_count_free_blocks (sb) ; 

buf->f_bavail = buf->f_bfree - le32_to_cpu(sb->u.ext2_sb. s_ 
es->s_r_blocks_count); 

if (buf->f_bf ree < le32_to_cpu (sb->u . ext2_sb. s_es->s_r_ 
blocks_count)) 
buf->f_bavail = 0; 

buf->f_files = le32_to_cpu (sb->u. ext2_sb. s_es->s_inodes_count); 
buf->f_ffree = ext2 一 count_free_inodes (sb) ; 
buf->f_namelen = EXT 2_NAME_LEN; 
return 0; 


static DECLARE_FSTYPE_DEV(ext2_fs_type f n ext2", ext2_read_super); 

static int _init init_ext2_fs (void) 

{ 

return register_filesystem(&ext2_fs_type); 

} 

static void _exit exit_ext2_fs (void) 

{ 

unregister_filesystem(&ext2_fs_type); 

} 

EXPORT_NO_SYMBOLS; 

module_init(init_ext2_fs) 
module_exit(exit_ext2_fs) 

원천파일 fs/ext2/file.c(2.4.3) 

/* 

* linux/fs/ext2/file.c 

* Copyright (C) 1992, 1993, 1994, 1995 

* Remy Card (card@masi.ibp.fr) 

* Laboratoire MASI 一 Institut Blaise Pascal 


* Universite Pierre et Marie Curie (Paris VI) 
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fsync : 


struct inode—operations ext2_file_inode_operations = 
truncate : 


fs/namei.c 안의 함수 open_namei () 의 원천쿄드 

int open_namei (const char * pathname, int flag, int mode, struct 
nameidata *nd) 

{ 

int acc_mode, error = Ob¬ 
struct inode *inode; 
struct dentry *dentry; 
struct dentry *dir; 
int count = 0; 

acc_mode = ACC_MODE(flag); 


* The simplest case - just a plain lookup. 

*/ 

if ( ! (flag & 0_CREAT) ) { 

if (path_init(pathname, lookup_flags(flag》, nd)) 
error = path_walk (pathname, nd) ; 
if (error) 

return error; 
dentry = nd - >dentry; 
goto ok; 


* Create - we need to know the parent. 

*/ 

if (path_init(pathname, LOOKUP_PARENT, nd)) 
error = path_walk (pathname, nd) ; 
if (error) 
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if (flag & 0_EXCL) 

goto exit_dput; 

if (d_mountpoint(dentry)) { 
error = -ELOOP; 
if (flag & 0_N0F0LL0W) 
goto exit_dput; 

while ( _follow_down (&nd->mnt f &dentry) && d_mountpoint 

dentry)); 

} 

error = -ENOENT; 

if (!dentry- 〉 d_inode) 
goto exit_dput; 

if (dentry- 〉 d_inode->i 一 op && dentry - 〉 d_inode - 〉 i_op- 〉 follow_link) 
goto do_link; 


ok : 


dput(nd - >dentry); 
nd-〉dentry = dentry; 
error = -EISDIR; 

if (dentry->d_inode && S_ISDIR(dentry->d_inode->i_mode) ) 
goto exit; 

error = 一 ENOENT; 
inode = dentry->d_inode; 
if (!inode) 

goto exit; 


error = -ELOOP; 
if (S_ISLNK(inode->i_mode)) 
goto exit; 


error = -EISDIR; 

if (S_ISDIR (inode->i_mode) && (flag & FMODE_WRITE) ) 
goto exit; 

error = permission(inode,acc_mode》; 
if (error) 
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if (flag & 0_TRUNC) { 

error = get_write_access (inode) ; 
if (error) 

goto exit; 


* Refuse to truncate files with mandatory locks held on 
them. 

V 

error = locks_verify_locked (inode) ; 
if (lerror) { 

DQUOT_INIT(inode) ; 

error = do_truncate (dentry, 0); 

} 

put_write_access(inode); 
if (error) 

goto exit; 

if (flag & FMODE_WRITE) 

DQUOT_INIT(inode) ; 


return 0; 


exit_dput : 

dput(dentry) ; 

exit : 

path_release(nd); 
return error; 


do_link : 

error = -ELOOP; 
if (flag & 0_N0F0LL0W) 
goto exit_dput; 

* This is subtle. Instead of calling do_follow_link () we do the 

* thing by hands. The reason is that this way we have zero 
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* and path_walk () (called from ->follow_link) honoring 
LOOKUP_PARENT. 

* After that we have the parent and last component, i.e. 

* we are in the same situation as after the first path_walk () . 

* Well, almost 一 if the last component is normal we get its copy 

* stored in nd->last. name and we will have to putname () it 
when we 

* are done. Proofs-like symlinks just set LAST—BIND. 

UPDATE_ATIME(dentry->d_inode); 

error = dentry->d_inode->i_op->follow_link(dentry f nd) ; 

dput(dentry) ; 

if (error) 

return error; 

if (nd->last_type == LAST_BIND) { 
dentry = nd - >dentry; 
goto ok; 

} 

error = -EISDIR; 

if (nd->last_type != LAST_NORM) 
goto exit; 

if (nd->last.name[nd->last.len]) { 
putname(nd->last.name); 
goto exit; 

} 

if (count++==32) { 

dentry = nd->dentry; 
putname(nd->last.name); 
goto ok; 

} 

dir = nd->dentry; 

down(&dir - >d_inode->i 一 sem); 

dentry = lookup_hash(&nd->last f nd->dentry); 

putname(nd->last.name); 

goto do_last; 
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제 5 장. 론리기록권관리기 LVM 

현재의 Linux 봉사기에는 3~10개 또는 그이상의 디스크들이 장비되여 있다. SCSI 통로와 
분기된 디스크카비 네 트는 여 러 개의 디 스크를 얼마든지 장비할수 있다. 그러 나 여 러 개의 디 
스크구획 (disk partition) 을 관리 하는 문제 는 헐 치 않다. 또한 Linux 체 계 관리 기 들은 어 떤 한개 의 
파일 체 계 가 공간을 거 의 100%차지하게 되 자 구획 을 아주 묘하게 확장할수 있 는 방법 을 모 
색하게 되 였 다. 이 때 LVM 을 리 용하면 이 문제 가 가능할뿐아니 라 아주 쉽 게 실 현될 수 있 다. 

LVM 은 UNIX 에서의 실현과정 을 거 처 사실상 표준기 억관리형 태 로 된 직 결 디스크 
기 억관리 용부분체 계 이 다. LVM 은 초기 에 AIX 조작체 계용으로 IBM 에 의하여 개 발되 였 으 
며 계 속하여 OSF/1 조작체 계 용으로 OSF (현재 OpenGroup) 에 의 하여 리 용되 였 다. 

OSF 판본은 그후 HP_UX 와 Digital UNIX 조작체계의 기초로 되였다. 이것이 바로 
LVM 들이 가동환경 들에 서 서 로 류사한 리유로 된 다. Linux 에 서 LVM 은 HP_UX LVM 과 
아주 류사하다. 일 반적 으로 Linux LVM 이 실현됨 으로써 인터네 트상에서 의 리용률이 대 단 
히 높아 졌다. 

LVM 은 파일체 계 와 기 록권을 관리하는 방법 을 완전히 새 롭게 고찰한다. LVM 은 구 
동기 들이 현재 구획표도식 을 리용하는것 보다 더 유연한 방법 으로 디 스크들을 주사하고 
크기 를 재 조직하며 관리할수 있 게 한다. 

LVM 에 대한 소개 

LVM 은 핵 심 부에 서 물리 적장치 들과 블로크 I/O 대 면부들사이 에 보충적 인 층을 추가 
한다. 실례 로 ex 任과 같은 파일체 계 는 디 스크구동기 를 직 접 사용할 대 신에 LVM 에 의하 
여 제공된 블로크장치를 사용한다. 

그림 5-1 에 LVM 에 의하여 도입 된 I/O 론리 의 보충적 인 계 층을 제 시하였 다. 

전통적 인 체 계 들에 서 디 스크구동기 들은 보통 련속적 인 기 억구역 으로 구획화(《 구 
획》혹은《 단편》)되며 블로크장치 로 넘겨 진다. PC 체계상에서 구획은 fdisk 와 같은 도 
구에 의하여 실 현되 며 이 때 fdisk 는 단순구획표를 보존하게 된다. 

실례로 디스크구동기 /dev/sda 는 n 개의 기억구역으로 구획화되며 구획들은 그림 5_2에서 
보여 준것처럼 /dev/sdan 을 통하여 /dev/sdal 과 련관되게 한다. 

결 함은 명 백한바 구획 은 크기 가 디 스크구동기 의 크기 로 제 한되 며 구획 의 크기 를 재 
설 정하는 과정 은 련속적 인 구획 들을 재 구성하거 나 혹은 여 벌 복사로 되 돌아 가지 않고 디 
스크를 재 조직하는 GNU parted* 와 같은 특별 한 도구를 사용할것 을 요구한다는것 이 다. 이 
것은 아주 위험 하고 모험적 인 조작이 다. 


많은 독자들은 Power Quest Corp 의 Partition Magic 와 더 익숙되였을것 이 다. 
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더 우기 LVM 은 디 스크자원들을 관리 하기 위한 종합적 인 관리틀을 가지 고 있 다. 

LVM 은 핵 심 부의 블로크(디 스크) 장치대 면부와 체 계 상의 실제 적물리장치사이 에 새 로 
운 층을 놓는 방법 으로 동작한다. 새 로운 론리《 장치》들은 하나 혹은 그이 상의 물리 적 
장치 부분들을 리용하여 만들수 있 다. 단순응용프로그람들은 다중구획(혹은 전체 구동기) 
을 단순하고 보다 큰 론리구동기 들과 결 합능력 을 가진 다. 

하지 만 LVM 의 우점 은 론리기 록권의 치 수를 재 빨리 변화시 킬수 있게 한다는데 있 다. 
구획이 너무 작아 지는 문제를 체험한 체계관리기는《더 크게 할수 있다》고 말하였다. 
체계를 지우거 나 여 벌복사，재구획구성，회복 등을 수행할 대 신에 현재는 간단히 lvextend 
명령을 줄수 있다. 

LVM 은 어떻게 동작하는가 

LVM 은 물리 적주변장치 들과 핵 심 부의 I/O 대 면부사이에 론리기 록권의 보충적 인 층 
즉 새 론리층을 추가한다. 이 층은 사슬형 식 으로 결 합된 여 러개의 디 스크(이 른바 물리 기 
록권)들이 물리범 위 라고 부르는 (PE) 배 정단위 에 의하여 기 억 풀 혹은 기 록권그롭을 형 성 
하게 한다. 다음 기 록권그룹외 의 부분들은 론리범 위 라고 부르는 (LE) 단위 로 론리기 록권 
의 형태로 배정될수 있다. 매 론리범위는 같은 크기의 대응하는 물리범위로 넘겨 진다. 
론리기록권들은 /deWVolumeGroupName/LogicarVolumeName 로 명 명되는 /dev/sd[a-z]* 혹은 
/dev/ hd[a_z]* 과 류사한 장치 전용파일을 통하여 리 용될수 있다. 

매 개 물리기 록권，기 록권그룹，론리기 록권에 관한 배 치구성 정 보는 기 록권그룹서술자 
구역 (Volume Group Descriptor Area 혹은 VGDA) 이 라고 부르는 구역의 물리 기 록권상에 기 
억된다. 이 정보를 쓸 때에 VGDA 는 물리적으로 상위블로크의 바로 뒤에 위치하게 되는 
데 이 것은 다음번 개 방에서는 변경될수도 있다. 배 치구성정 보는 자동적 으로 생 성되는 여 
벌복사파일에 기억되며 이 파일은 / etc/lvmtab.d 등록부에 기억된다. 

LVM 구동기는 론리기 록권의 론리적범위 와 물리기록권의 물리적범위사이의 넘기기 표 
를 보존한다. 이 표들은 상위사용자 LVM 명 령 들에 의하여 생 성되 고 갱 신되 며 또한 지 워 
진 다 . 구 동 기 의 기 본 넘 기 기 함 수 는 /usr/src/linux/driver/block/ ll_rw_blk.c 파 일 에 있 는 
ll_rw_block(), ll_rw_swap_file() 함수들로부터 론리 기륵권에 있는 론리 적 블로크를 호출한다. 
넘기기함수는 표안에서 대응하는 물리블로크/디스크쌍을 검색한다. 다음 디스크블로크들 
에 대한 물리적 I/O 요청이 대기렬로 형성되게 하는 ll_rw_*() 함수에 이 쌍을 귀환시킨다. 
Linux 에서 블로크장치는 단순한 구동기 이며 이 구동기는 buffer_head 들을 얻고 기 억장치 
들로부터 자료를 채우든가 혹은 기 억 장치 에 그 자료를 써 넣는다. 

특히 장치구동기 가 서 로 다른 장치 지 어 여 러 개 장치 들에 다른 FO 를 수행하여 VO 
요청을 만족시 킬수 있게 한다. 

LVM 과 쏘프트웨 어 RAID 구동기 는 하나 혹은 그이 상의 I/O 들을 론리기 록권이 나 RAID 
묶음에 속하는 하나 혹은 그이상의 디스크들에 관하여 실행시켜 가상장치 에 대 한 I/O 를 
실현하도록 하는 우점을 가지고 있다. 

LVM 혹은 RAID 구동기 에 대 한 단일!/ O 는 토대층디 스크에 대 한 단일!/ O 를 실현시 킬 
때 리용되는 특정한 최량화이다. 이 경우에 실제적으로 토대층디스크에 보내야 할새로 
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운 I / O 조작을 생성할 필요는 없다. 실제적 으로 론리장치 즉 주어 진 물리장치 가 기동시 
에 올려태우기된 블로크장치보다 다른 물리장치에 대하여 동작이 진행되여야 한다는것을 
통보하기 위 하여 론리 장치 는 읽혀 지거 나 써지 는 buffer _ head 에 표식 자를 붙인다. 

디 스크나 구획(혹은 그것 들이 새 롭게 호출되 는 기 록권그를/론리그룹)들은 장치 의 가 
상적표현이기때문에 실행시에도 론리기록권을 쉽게 늘이거나 줄일수 있다. 

이제 LVM 이 이러한 기능들을 내부적으로 어떻게 실현하는가를 보자. 

LVM 의 내부 

물리 기륵권이 나 기 록권그룹 ( volg ) 그리고 론리 기륵권 ( lvol ) 을 생성할 때 이 것들의 매 
론리적실체에 관한 배치구성정보는 대응하는 물리기록권에 기억되며 이 정보의 여벌복사 
는 / etc / lvmtab . d 등록부밑 에 자동적 으로 주어 진다. 

핵심부 2.3.49 로부터 시 작하여 LVM 구동기는 핵심부안에 내장되여 있다. 이 구동기들 
은 volg 와 론리기록권 그리고 대응하는 물리구획과 구동기사이의 넘기기표를 가지고 있 
다. 이 표들은 LVM 명 령 들을 생 성 하고 유지 하는데 이 LVM 명 령 들은 뿌리만이 실 행할수 
있 다. 

LVM 관리용 lvol 상의 한개 파일체계에 포함되여 있는 한개의 블로크에 대한 접근이 
요구될 때 마다 구동기는 해 당 블로크를 그 디 스크상의 실제주소로 넘 기기하는데 이 표를 
리 용한다. 

넘기기표의 리용 

우리 가 4개의 디스크를 포함하는 체 계를 가지 고 있다고 하자. 한개는 조작체계용이 
고 다른 3개 는 자료용이다. LVM 은 현재 4개 의 디 스크가 있 다는것 을 알고 있 다. 왜 냐하 
면 핵심부가 기동시에 디스크들을 검출하며 또 디스크목록으로 된 표를 보존하고 있기때 
문이 다. 이 제 해 야 할것 은 매 개 디 스크에 대 하여 하나의 기 록권그룹을 생 성하는것 이 다. 
매 파일체 계 에 대 하여 필요하다면 개 별적 론리 기 록권을 계속 생성할수도 있다. 


/dev/volgol/lvolroot 

for the OS 

/800MB#this is one of two lvols for the 

2GB disk used 

/dev/volgol/lvolusr 

/usr 1200MB # and this is the 

seond,for /usr 

/ dev/volgo2 / lvolhome 

/home 9000MB # 

/ dev/volgo3/lvoldbf 

/ora_data 9000MB # this might actually 

be a RAID device 

/ dev/volgo4 / lvolidx 

/ora_idx 
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이제 우리 가 어떤 공간밖에서 례를 들어 /home 등록부밖에서 실행하며 사용자들이 굉 
장히 큰 MP3 등록부라든지 동화상파일들중에서 어떤것을 지울수 없다고 가정 하자. Linux 
에서는 아직 재 치 있게 디스크공간을 생성할수 없기때문에 다른 디스크를 얻어야 할것 이 
다. 현재 디 스크들은 대 다수 18GB 에 도달하고 있다. 이 제 새 그롭에 대 하여 /dev/volgo2 
기 록권디 스크의 4GB 구획 을 지 정한다. 그러 면 LVM 을 리용하여 최 대 13GB 로 lvolhome 론 
리기 록권을 확장하여 나간다(명 백 히 volgo2 를 더 주지 않은 조건에 서 ). 만약 현재 봉사기 
가 가속-교환디스크추가기능을 지원한다면 재기동할 필요가 없으며 /home 은 곧 커지게 
된다. 이때 일련의 경고가 있을수 있다. 

첫째로 /home 등록부로부터 사용자들을 순간적으로 분리시켜야 한다. 핵심부는 파 
일들이 그안에 아직 열 려 져 있으면 /home 등록부의 올려태 우기해제 를 하지 않게 된다. 
대 표적 으로 봉사기상에서 모든 망동작(사용등록가입 등)을 순간동안 정지시키 기 위하 
여 콤퓨터 를 단일 사용자방식 으로 설 정 하고 자기 에 게 필 요한 실 행준위 (runlevel) 로 돌 
아 간다. 

둘째 로 LVM 을 리용하여 필요할 때 마다 공간을 추가해 야 한다. 그리 고 사용자들은 
인차 지워 지지 않는 등록부들에 모든 종류의 불필요한것들을 넣을수 있다. 

몇가지 명령실례들 

핵 심 부 2.3.49+ 를 가지 고 있거 나 혹은 현재 핵 심 부에 LVM 으로 검 사수정한다고 할 
때 우에서 언급된 내용들을 수행하기 위하여 다음의 명령에 대한 실례들을 실행시킬 
수 있다. 

1. LVM 을 설 치 한후 “lnsmod lvm” 을 수행 하거 나 혹은 그것 을 자동적 으로 적 재 하기 
위 하여 kerneld/kmod 를 설 정 한다 (INSTALL 을 볼것 ). 

2. 구획 형 Ox8e 로 두개 의 디 스크상에 구획 (#1) 을 설 정한다. 

3. “pvcreate/dev/sd[ce]l ” 을 수행 한다. 검 사를 목적 으로 하나의 디 스크상에 한개 이 상 
의 1차구획 이 나 혹은 확장된 구획 을 리용할수 있 다. 

4. “vgcreate volg02/dev/sd[ce] 1” 을 수행 한다 (vgcreate 도 역 시 기 록권그룹을 활성 화 
한다.). 

5. 100MB 의 선형론리기 록권을 얻 기 위 하여 서 는 * l lvcreate-lvoldbf_lv tvolg02 ，> 을 수 
행하거 나 혹은 두개 의 구획 분할과 4KB 의 구획 분할크기 를 가진 1000MB 이 상의 큰 
론리 기 록권을 얻 기 위 하여 “lvCTeate-i2-14-11000-nlvoldbf volg02” 를 수행 한다. 

6. 요구될 때 생 성된 LV 를 리용한다. 실례 로 “mke2fs/dev/volg02/lvoldbf” 로 파일체 
계를 생성하고 그것을 올려 붙인다. 

Linux LVM 은 HP_UX 개 념 즉 명 령 들과 밀접 히 동반되 기 때 문에 이 름과 동작에 서 
거 의 같다. 그러 므로 물리기 록권을 조종하기 위한 명 령 들은 모두 pv 로 시 작하며 론 
리그룹조종을 위한 명 령 들은 vg 로，론리기 록권을 조종하기 위한 명 령 들은 lv 로 시 작 
한다. 
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표- 2 _ LVM 명령들 


명 령 

기 ♦ 

2fsadm resizing for lvextend, 

lvreduce, e2fsck and resize2fs 

파일체계를 포함하는 론리기록권을 위한 관리계층 

lvchange 

론리기록권의 속성변화 

lvcreate 

론리기록권의 생성 

lvdisplay 

론리기록권구성자료현시 

lvextend 

론리기록권의 치수확장 

lvreduce 

론리기록권의 치수감소 

lvrename 

비 사용론리 기 록권의 이 름바꾸기 

Lvscan 

존재하는 모든 론리기록권찾기 

lvmchange 

LVM 의 속성변화를 위한 긴급프로그람 

lvmdiskscan 

모든 디스크/구획，다중장치와 그것들의 목록주사 

lvmsadc 

정 적 자료수집 자 

lvmsar 

정적자료보고자 

pvchange 

물리기 록권의 속성변화 

pvcreate 

물리기록권생성 

pvdata 

물리기 록권그룹서술자구역목록의 디 버 그 

pvdisplay 

물리기록권배치구성의 연시 

pvmove 

론리적크기를 다른 물리기록권으로 이동 

pvscan 

존재하는 모든 물리기 록권찾기 

vgcfgbackup 

모든 기 록권그를서 술자구역 의 여 벌 복사 

vgcfgrestore 

기 록권그를서 술자구역 의 디 스크로의 회 복 

vgchange 

능동/비 능동기록권 그를 

vgck 

일 관성 을 위한 기 록권그룹서술자구역 의 검 사 

vgcreate 

물리기 록권으로부터 기 록권그룹생 성 

vgdisplay 

기 록권그룹배 치구성정 보 연시 

vgexport 

기록권그를내보내기(체계에 알려 지지 않게) 

vgextend 

하나 혹은 그이 상의 물리기 록권에 의하여 기 록권그룹확장 

vgimport 

기록권그룹의 입수(체계 혹은 다른 체계에 알려 지게) 

vgmerge 

두개 기록권그룹을 하나로 련결 

vgmknodes 

모든 론리기 록권전문에 의 한 기 록권그를등록부생성 

vgreduce 

하나 혹은 그이 상의 자유물리기 록권에 의한 기 록권그를축소 

vgremove 

빈 기록권그룹제거 

vgrename 

비능동기 록권그룹의 이 름바꾸기 

vgscan 

기록권그률에 대한 주사 

vgsplit 

한개 기록권그룹을 두개로 분할 
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LVM 용물리기록권생성 


LVM 은 전체 물리기 록권들이 기 록권그룹으로 지 적될것 을 요구하므로 LVM 이 리용할 
수 있게 준비된 몇개의 빈 구획을 가지고 있어야 한다. 몇개의 구획상에 OS 를 설치하고 
빈 공간을 좀 남겨 둔다. 갈은 크기 를 가진 몇개의 빈 구획 을 생성하기 위하여 Linux 상에 
서 fdisk 를 리용한다. fdisk 를 리용하여 그 구획 들에 형 OxFE 로 표식 을 달아야 한다. 이 렇 
게 하여 5개 의 256 MB 의 구획 / dev / hda 5~/ dev / hda 9 를 생 성한다. 

들리기록권의 등록 

LVM 을 실 행하는데 필요한 첫번째 과제 는 LVM 에 물리기 록권을 등록하는것 이 다. 이 
과 정 은 pvcreate 명 령 을 통 하 여 수 행 된 다 . 만 들 려 는 매 개 hdxx 장 치 에 대 하 여 
pvcreate / dev / hdxx 을 간단히 실행하면 된다. 우리의 경우에는 실례 로 pvcreate / dev / hda 5 등으 
로 실 행한다. 

기록권그룹의 생성 

다음 기록권그룹을 만든다. 기록권그를생성명 령 에 물리적범위의 크기와 같은 어떤 
인수들을 설정할수는 있으나 대체 로 기정값을 리용하는것 이 좋다. 새 로운 기록권그를 
vgol 을 호 출 한 다 . 즉 vgcreate / vgol / dev / hda 5 를 건 입 력 한 다 . 이 명 령 이 수 행 된 다 음 
vgdisplay 명 령 으로 기 록권그롭을 본다. 여 기서 256개까지 론리 기 록권을 생성 할수 있고 
256개 까지 물리기 록권을 추가할수 있 으며 매 개 론리기 록권은 255.99 GB 까지 될 수 있 다는 
데 대 하여 주의해 야 한다. 보다 중요하게는 빈 물리 적범위 ( PE ) 렬 에 대 한것 이 다. 이것 은 
론리기록권들을 생성할 때 작업할수 있는 물리적범위가 몇개나 될수 있는가를 말해 준 
다. 256 MB 디스크에 대 하여 이 값은 크기 가 4 GB 인 물리 적범위보다 작은 쓰지 못하는 나 
머지가 존재하기때문에 63으로 된다. 

론리기록권의 생성 

다음으로 Vg vgol 이 라고 부르는 론리기 록권을 만들어 보자. 론리기 록권을 만들 
때 변경시켜도 일 없는 몇가지 설정항목이 존재하지만 역시 기정값을 쓰는것이 좋 
다. 생성하는데서 중요한 선택항목 ( option ) 은 해당 론리기록권우에 론리적범위를 몇 
개 배 정하겠는가 하는것 이 다. 이 제 총 16 MB 의 크기 에 대 하여 4개 를 가지 고 출발하 
겠 다. 

Lvcreate -14 -nlvol vgol 을 건 입 력한다. 

-1 대 신 - L 을 리용하여 MB 단위 로 크기 를 정 의할수도 있 으며 이 때 LVM 은 가장 가까 
운 론리 적범위의 크기중복은 둥그리 기하여 잘라 버린다. 

이 제 lvdisplay 명 령 으로 lvdisplay - v / deWvgol / lvol 을 건 입 력 하여 론리 기 록권을 볼수 있 
다. 이제부터 는 론리범위폐지 를 무시할수도 있고 보다 흥미 있는 자료들을 보기 위하여 
페지를 우로 올릴수도 있다. 
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기록권그룹에 디스크의 추가 


다음으로 / dev/hdab 을 기록권그롭에 추가하겠다. 

vgectend vgol 八 iev/hda 을 건 입 력하여 수행한다. 

이것을 vgdisplay-v vgol 을 리 용하여 검사할수 있다. 보다 더 많은 PE (물리 범위)들이 
존재할수 있 다는것 을 강조한다. 

구획분할 ( st 『 iped ) 된 론리기록권생성 

LVM 이 기록권그룹안의 한개 물리기록권에 대하여 옹근 하나의 론리기록권을 생성했다 
는것을 강조한다. Lvcreate 명 령 에 _1기발을 설정하여 lv 를 두개의 물리기록권으로 구획분할할 
수 있다. 이제 새 로운 론리 기록권 lvo 2 를 생성 하고 hda 5 와 hda 6 으로 구획분할하겠다. 

lvcreate - I 4- nlvo 2- i 2 vgol / dev / hda 5/ dev / hda 6 을 건 입 력한다. 

명령선상에서의 물리기록권의 정의는 LVM 이 어느 물리적범위를 리용하겠는가를 지 
적하며 한편 _ i 2 명 령 은 두개 의 기 록권으로 구획 분할한다는것 을 지 적한다. 따라서 현재 우 
리 는 두개 의 물리기 록권으로 구획 이 분할된 한개 의 론리기 록권을 가지 게 된 다. 

기록권그룹안에서 자료의 이동 

지금까지 물리적범위와 론리적범위는 거의 호환적이 였다. 이것들용 크기도 같고 또 
LVM 에 의하여 자동적 으로 넘 기 기된다. 하지 만 이것은 사실상 그렇지 않다. 디스크가 올 
려태 우기 되 여 리용중에 있 어 도 하나의 pv 로부터 다른것 에 로 전체 lv 를 옮길수 있 다. 이 것 
은 체 계성능에 는 영 향을 주지 만 쓸모 있게 개선할수 있다. 

hda 5 로부터 hda 6 으로 lv 이을 옮기 자. 

Pvmove - n / dev / vgol/lvol 八 iev / hda 5/ dev / hda 6 을 건입 력한다. 이 명 령은 / dev / hda 5 의 모표들에 
넘 기 기된 lvol 이 리 용하는 모든 LE 들을 / dev / hda 6 의 새 로운 PE 들로 옳긴다. 이 과정 에 따라 
hda 5 로부터 hda 6 으로 효과적 으로 자료가 옮겨 진다. 조작실행 후 lvdisplay - v / dev / vgol/lv 이로 
결과를 볼수 있으며 자료가 총체적 으로 / dev / hda 6 에 존재 한다는것을 알수 있다. 

기록권그룹으로부터 론리기록권제거 

이 제 더 이 상 lv 02 이 필 요없 다고 하자. 이 런 경 우 우리 는 그것 을 제 거할수 있 으며 기 
록권그롭을 위한 빈 풀 ( pool ) 에 론리기록권들의 PE 들을 돌려 보낼수 있다. 우선 그것의 
파일 체 계 를 올려 태 우기 해 제 한다. 다음 lwhange -a n 八 leWvg 01/ lv 02 를 리 용하여 그것 을 비 
능동상태 로 만든다. 마지 막으로 Ivremove / dev / vg 01/ lv 02 를 건 입 력 하여 지 운다. 기 록권그를 
을 보고 모표들이 현재 사용되지 않는다는것을 알수 있다. 

기록권그룹으로부터 디스크의 제거 

기 록권그룹으로부터 디 스크를 역 시 제 거할수 있 다. 이 제 hda 5 를 더 이 상 리용하지 않 
으면 그것 을 기 록권그룹으로부터 제 거할수 있 다. 

Vgreduce vg 01/ dev / hda 5 를 건 입 력하면 제 거 동작이 실 현된 다. 
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원천 a 드 include / linux / lvm.h 


/* include/linux/lvm.h 

* kernel/lvm.h 

* tools/lib/lvm.h 


* Copyright (C) 1997 - 2000 Heinz Mauelshagen, Sistina Software 

* February - November 1997 

* May-July 1998 

* January-March f July,September,October,Dezember 1999 

* January,February,July,November 2000 

* January - March 2001 

* lvm is free software; you can redistribute it and/or modify 

* it under the terms of the GNU General Public License as published by 

* the Free Software Foundation; either version 2, or (at your option) 

* any later version. 

* 

* lvm is distributed in the hope that it will be useful, 

* but WITHOUT ANY WARRANTY; without even the implied warranty of 

* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 

* GNU General Public License for more details. 

* 

* You should have received a copy of the GNU General Public License 

* along with GNU CC; see the file COPYING. If not, write to 

* the Free Software Foundation, 59 Temple Place 一 Suite 330, 

* Boston, MA 02111-1307, USA. 


* Changelog 

* 10/10/1997 一 beginning of new structure creation 

* 12 / 05/1998 - incorporated structures from lvm_vl.h and deleted 

lvm_vl.h 

* 07/06/1998 - avoided LVM_KMALL0C_MAX define by using 
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vmalloc/vfree 


instead of kmalloc/kfree 


01/07/1998 - fixed wrong LVM_MAX_SIZE 

07/07/1998 一 extended pe_t structure by ios member (for 


02/08/1998 一 changes for official char/block major numbers 
07/08/1998 一 avoided init_module() and cleanup 一 module() to be 


static 


29/08/1998 一 separated core and disk structure type definitions 
01/09/1998 - merged kernel integration version (mike) 

20/01/1999 - added LVM_PE_DISK_OFFSET macro for use in 
vg_re ad_w i t h_pv_and_lv () , pv_move_pe () , 


pv_show_pe_text () . . . 

18/02/1999 - added definition of time_disk_t structure for; 


keeps time stamps on disk for nonatomic writes 
(future) 


15/03/1999 一 corrected LV() and VG() macro definition to use 


argument 
instead of minor 

03/07/1999 - define for genhd.c name handling 
23/07/1999 - implemented snapshot part 

08/12/1999 - changed LVM_LV_SIZE_MAX macro to reflect current 
1TB limit 

01/01/2000 - extended lv_v2 core structure by wait_queue member 
12/02/2000 - integrated Andrea Arcagnelli 1 s snapshot work 
18/02/2000 - seperated user and kernel space parts by 
#ifdef them with 一 KERNEL 一 

08/03/2000 一 implemented cluster/shared bits for vg_access 
26/06/2000 一 implemented snapshot persistency and resizing support 
02/11/2000 一 added hash table size member to lv structure 
12/11/2000 - removed unneeded timestamp definitions 
24/12/2000 - removed LVM_TO_{CORE,DISK}*, use cpu_{from / to}_le* 
instead 一 Christoph Hellwig 
22/01/2001 - Change ulong to uint32_t 
14/02/2001 - changed LVM_SNAPSHOT_MIN_CHUNK to 1 page 
20/02/2001 一 incremented I OP version to 11 because of incompatible 
change in VG activation (in order to support 
devfs better) 

01/03/2001 - Revert to IOP10 and add VG_CREATE_OLD call for 










compatibility 

* 08/03/2001 - new lv_t (in core) version number 5 : changed page 

member 

* to (struct kiobuf *) to use for COW exception 

table io 

* 26/03/2001 - changed lv_v4 to lv_v5 in structure definition (HM) 

#ifndef _LVM_H_INCLUDE 
#define _LVM_H_INCLUDE 

#define LVM_RELEASE_NAME T, 0.9.1_beta7 n 
#define LVM_RELEASE_DATE n 10/04/2001 f, 

#define _LVM_KERNEL_H_VERS I ON f, LVM f, LVM_RELEASE_NAME " 

( f, LVM_RELEASE_DATE f, ) " 

#include <linux/version.h> 

* preprocessor definitions 

/* if you like emergency reset code in the driver */ 

#define LVM_TOTAL_RESET 

#ifdef 一 KERNEL 一 

#undef LVM_HD_NAME /* display nice names in /proc/partitions */ 

/* lots of debugging output (see driver source) 

#define DEBUG_LVM_GET_INFO 
#define DEBUG 
#define DEBUG_MAP 
#define DEBUG_MAP_SIZE 
#define DEBUG_IOCTL 
#define DEBUG_READ 
#define DEBUG_GENDISK 
#define DEBUG_VG_CREATE 
#define DEBUG_DEVICE 
#define DEBUG_KFREE 
172 













： ONFIG_ARCH_S390 










#define MAX_LV ABS_MAX_LV 
















.SIZE 


es on disk */ 

SK_BASE (LVM_T IME S TAMP_D I SK_BASE + \ 
LVM_TIME S TAMP_DISK_SIZE) 


culated parts of the VGDA */ 

’(a, b) ( (a) - >lv_on_disk .base + \ 
sizeof ( lv_disk_t) * b) 

( (pv)->pe_on_disk.base + \ 

(pv)->pe_on_disk.size) 

’ (pe, pv) ( pe * pv->pe_size + \ 

( LVM_DISK_SIZE ( pv) / SECTOR_SIZE) ) 

E (pv) \ 

>lv_on_disk.base + pv->lv_on_disk.size; \ 
.sk.base % SECTOR_SIZE) != 0) \ 




/* This is the usable size of pe_disk_t. le_num ! ! ! v v */ 

#define LVM_PE_T_MAX ( ( 1 « ( sizeof ( uintl6_t) *8 》》 一 2) 


#define LVM_LV_SIZE_MAX (a) ( ( long long) LVM_PE_T_MAX * (a)- 

>pe_size > ( long long) 1024*1024/SECTOR_SIZE*1024*1024 ? ( long long) 
1024*1024/SECTQR_SIZE*1024*1024 : ( long long) LVM_PE_T_MAX * (a)- 


( 8192L / SECTOR_SIZE) /* 8 KB in 


16L * 1024L * 1024L / SECTOR_SIZE : 


#define 
sectors */ 

#define LVM_MAX_PE_SIZE 

1024) /* 16GB in sectors */ 

#define LVM_DEFAULT_PE_S I ZE ( 4096L * 1024 / SECTOR_SIZE) /* 4 MB 
in sectors */ 

#define LVM_DEFAULT_STRIPE_SIZE 

#define LVM_MIN_STRIPE_SIZE 

PAGESIZE in sectors */ 

#define LVM_MAX_STRIPE_SIZE 

in sectors */ 


16L 


16 KB */ 


( PAGE_SIZE/SECTOR_SIZE) 

( 512L * 1024 / SECTOR_SIZE) 


#define 
#define 
1024) " 
#define 
#define 
#define 
#define 
use) */ 
#define 
#define 


LVM_MAX_STRIPES 
LVM_MAX_SIZE 
1TB[sectors] */ 
LVM_MAX_MIRRORS 
LVM_MIN_READ_AHEAD 
LVM_MAX_READ_AHEAD 
LVM_MAX_LV_10_T IMEOUT 


128 /* max # of stripes */ 

( 1024LU * 1024 / SECTOR_SIZE * 1024 * 

2 /* future use */ 

2 /* minimum read ahead sectors */ 

120 /* maximum read ahead sectors */ 

60 /* seconds I/O timeout (future 


LVM_PARTITION Oxfe 

LVM_NEW_PARTITION 0x8e 

(10/09/1999) */ 

#de fine LVM_PE_SIZE_PV_SIZE_REL 

PE size */ 


LVM partition id */ 
new LVM partition id 


: max relation PV size and 


#define LVM_SNAPSHOT_MAX_CHUNK 1024 /* 1024 KB */ 

#define LVM_SNAPSHOT_DEF_CHUNK 64 /* 64 KB */ 

#define LVM_SNAPSHOT_MIN_CHUNK (PAGE_SIZE/1024) /* 4 or 8 KB */ 


#define UNDEF -1 
#define FALSE 0 
#define TRUE 1 
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#define LV_ACTIVATE _I0 ( Oxfe, 0x22) 

#define LV_DEACTIVATE _I0 ( Oxfe, 0x23) 

#define LV_EXTEND _IOW ( Oxfe, 0x24, 1) 

#define LV_REDUCE _IOW ( Oxfe, 0x25, 1) 

#define LV_STATUS_BYNAME _IOWR ( Oxfe, 0x26, 1) 

#define LV_STATUS_BYINDEX _IOWR ( Oxfe, 0x27, 1) 

#define LV_SET_ACCESS _IOW ( Oxfe, 0x28 f 1) 

#define LV_SET_ALLOCATION _IOW ( Oxfe, 0x29, 1) 

#define LV_SET_STATUS _IOW ( Oxfe, 0x2a, 1) 

#define LE_REMAP _IOW ( Oxfe, Ox2b f 1) 

#define LV_SNAPSHOT_USE_RATE _IOWR ( Oxfe, 0x2c, 1) 

#define LV_STATUS_BYDEV _IOWR ( Oxfe, 0x2e, 1) 

#define LV_RENAME _IOW ( Oxfe, 0x2f, 1) 

#define LV_BMAP _IOWR ( Oxfe, 0x30, 1) 

/* physical volume */ 

#define PV_STATUS _IOWR ( Oxfe, 0x40, 1) 

#define PV_CHANGE _IOWR ( Oxfe, 0x41, 1) 

#define PV_FLUSH _IOW ( Oxfe, 0x42, 1) 

/* physical extent */ 

#define PE_LOCK_UNLOCK _IOW ( Oxfe, 0x50, 1) 

/* i/o protocol version */ 

#define LVM_GET_IOP_VERSION _IOR ( Oxfe, 0x98, 1) 

#ifdef LVM_TOTAL_RESET 

/* special reset function for testing purposes */ 

#define LVM_RESET _IO ( Oxfe, 0x99) 

#endif 
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#else 


char dummy[200]; 
#endif 
} lv_v5_t; 


typedef struct { 

uint8_t lv_name [ NAME_LEN ] ; 
uint8_t vg_name [NAME_LEN] ; 
uint32_t lv_access; 
uint32_t lv_status; 
uint32_t lv_open; /* HM */ 

uint32_t lv_dev; /* HM */ 

uint32_t lv_number; /* HM */ 

uint32_t lv_mirror_copies; /* for future use */ 
uint32_t lv_recovery; /* " */ 

uint32_t lv_schedule; /* " */ 

uint32_t lv_size; 


uint32_t lv_snapshot_minor;/* minor number of original */ 


uintl6_t 1v_chunk_siz e; 
uintl6_t dummy; 
uint32_t lv_allocated_le; 
uint32_t lv_stripes; 
uint32_t 1v_stripesize; 
uint32_t lv_badblock; 
uint32_t lv_allocation; 
uint32_t lv_io_timeout; 
uint32_t lv_read_ahead; 


/* chunk size of snapshot */ 

/* for future use */ 

/* for future use */ 

/* HM */ 


* Structure Volume Group (VG) Version 1 

/* core */ 
typedef struct { 

char vg_name [NAME_LEN] ; /* volume group name */ 
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uint vg_number; 
uint vg_access; 
uint vg_status; 
uint lv_max; 
uint lv_cur; 
uint lv_open; 
uint pv_max; 
uint pv_cur; 
uint pv_act; 
uint dummy; 
uint vgda; 
uint pe_size; 
uint pe_total; 
uint pe_allocated; 


/* volume group number */ 

/* read/write */ 

/* active or not */ 

/* maximum logical volumes */ 

/* current logical volumes */ 

/* open logical volumes */ 

/* maximum physical volumes */ 

/* current physical volumes FU */ 

/* active physical volumes */ 

/* was obsolete max_pe_per_pv */ 

/* volume group descriptor arrays FU */ 
/* physical extent size in sectors */ 

/* total of physical extents */ 

/* allocated physical extents */ 


uint pvg_total; /* physical volume groups FU */ 

struct proc_dir_entry *proc; 


pv_t *pv[ABS_MAX_PV + 1 ] ; /* physical volume struct pointers */ 

lv_t * 1 v [ABS_MAX_LV + 1] ; /* logical volume struct pointers */ 

} vg_vl_t ; 


typedef struct { 

char vg 一 name [NAME—LEN] ; /* volume group name */ 
uint vg_number; /* volume group number */ 

uint vg_access; /* read/write */ 

uint vg_status; /* active or not */ 


uint lv_max; 
uint lv_cur; 
uint lv_openj 
uint pv_max; 
uint pv_cur; 
uint pv_act; 


/* maximum logical volumes */ 

/* current logical volumes */ 

/* open logical volumes */ 

/* maximum physical volumes */ 

/* current physical volumes FU */ 
/* active physical volumes */ 


uint dummy; 
uint vgda; 
uint pe_size; 
uint pe_total; 
uint pe_allocated; 
uint pvg_total; 


/* was obsolete max_pe_per_pv */ 

/* volume group descriptor arrays FU */ 
/* physical extent size in sectors */ 

/* total of physical extents */ 

/* allocated physical extents */ 

/* physical volume groups FU */ 


struct proc_dir_entry *proc; 
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kdev_t lv_dev; 
kdev_t pv_dev; 
uint32_t pv_offset; 
} data; 

} pe_lock_req_t; 


/* Request structure LV_STATUS_BYNAME */ 
typedef struct { 

char lv_name [NAME_LEN] ; 
lv_t *lv; 

} lv_status_fc>yname_req_t, lv_req_t; 


/* Request structure LV_STATUS_BYINDEX */ 
typedef struct { 

uint32_t lv_index; 
lv_t *lv; 

/* Transfer size because user space and kernel space differ */ 
ushort size; 

} lv_status_byindex_req_t; 

/* Request structure LV_STATUS_BYDEV. .. */ 
typedef struct { 
dev_t dev; 
lv_t *lv; 

} lv_status_bydev_req_t ; 

/* Request structure LV_SNAPSHOT_USE_RATE */ 
typedef struct { 

int block; 
int rate; 

} lv_snapshot_use_rate_req_t ; 


#endif 


/* #ifndef _LVM_H_INCLUDE */ 
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제 6 장 . Linux 용 RAID 

현재 Linux 용파일 체 계 의 조종하에 핑 장히 많은 자료가 RAID 디 스크장치 에 기 억 되 여 
있다. 따라서 Linux 가 RAID 장치를 어떻게 관리 하는가에 대 한 총체적 인 리 해를 가지는것 
은 아주 중요하다. 

RAID 의 기술적실현문제는 이 책에 밝혀 져있지 않기때문에 RAID 를 어떻게 제대로 
리용하겠는가에 대 하여 주의 를 돌리 겠 다. 이 장은 RAID 를 실제 적 으로 설 치하는것 과 또 
Linux 핵 심 부의 현재 배 포판을 리용하여 RAID (Redundant Array of Inexpensive/Independent 
Disk) 를 배 치구성하는것 이 얼마나 쉬운가를 보여 주게 된다(이 책의 경 우 2.4.0). 

인 텔 PC 장치상에 서 RAID 를 실 현 하는 방법 에 는 3 가지 가 있 다. 가장 공통적 인 방법 은 
PCI SCSI RAID 조종장치 의 리 용이 다. Linux 상에 서 이 방법 을 리 용하는데 서 문제 는 고속 
말단(고속-사용자)이 많고 프로그람작성정 보를 얻 기 위하여 NDA 를 요구하는것 이 다. 이 
NDA 는 원천코드를 개 방할수 없는것 으로 하여 무료쏘프트웨어 를 금지 하고 있다. 

Linux 하에서 RAID 를 실현하는 공통적 인 방법의 다른 하나는 SCSI 대 SCSI RAID 조종 
장치 를 리 용하는것 이 다. 이 방법 은 SCSI 를 지 원 하는 조종장치 를 요구한다(이 것 들중에 는 
여러가지가 있다.). 

그러한 조종장치의 모선상에 는 RAID 조종장치 가 있으며 이 것은 하나 혹은 그이상의 
장치들일수 있다(조종장치 에 배 럴을 어 떻게 설정하는가에 따라). 

RAID 조종장치는 배 렬을 포함하는 물리적장치들과 련결된 자체의 SCSI 모선을 가지 
고 있다. 

우리 는 RAID 배 렬을 설정 하기 위하여 임의 의 블로크지원장치(正®디 스크， SCSI 등)를 
리용할수 있 다. RAID 의 모든 조작들은 핵 심 부의 스레 드들에 의하여 조종된 다. 이 스레 드 
들은 Linux 핵 심 부들로부터 완성 된 형 태 로 리 용할수 있 을것 이 다. 

쏘프트웨 에 IAID 는 관리 응용프로그람들과 함께 핵 심 부모둘들의 모임이 며 이 때 관리 응 
용프로그람들은 순수 프로그람적 으로 RAID 를 실현하며 특정한 장치 를 요구하지 않는다. 

Linux 의 RAID 부분체 계 는 저 준위 디 스크구동기 (IDE, SCSI, paraport 구동기 등)와 블로 
크장치대면부우에 놓여 있는 핵심부의 한개 층으로 실현된다. 

ext2fs, DOS-FAT 등의 파일 체 계 는 블로크장치대 면부우에 놓인 다. 자체 의 고유한 속 
성 에 의하여 쏘프트웨 에 IAID 도 장치적해결책보다 더 유연한 해결책 을 지 향한다. 부족점 
은 대 등한 장치 체 계보다 CPU 주기 가 더 많이 요구되 고 실행 에 필요한 전력 도 더 많이 요 
구된 다는데 있 다. 

쏘프트웨 에 IAID 는 보다 중요한 하나의 구별 되 는 특성 을 가지 고 있다. 그것 은 구획 
대 구획 에 기 초하여 동작하며 여 기 서 여 러 개 의 개 별 적 디 스크구획 들은 RAID 구획 을 생 성 
하기 위하여 서 로 동시작용한다. 이 방법 은 전체 디 스크구동기 를 한개 배 렬로 동시동작 
시키는 대다수의 장치 RAID 방법과는 대조적이다. 

장치 적해 결방식 으로서 의 RAID 배 렬 이 있 다는 사실은 관리 를 단순화하려 는 목적 을 가 
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진 조작체계에 대해서는 명백하다. 프로그람적해결방식에 의거하면 보다 많은 선택성을 
가지지만 조작이 복잡해 진다. 


PCI 조종장치 

현재 Linux 에서 리용할수 있거 나 지원되는 장치에는 두개의 PCI SCSI RAID 조종장치 
즉 DPT 와 ICP-vortex 가 있 다. Linux 개 발자들도 역 시 Mylex 카드의 지 원 하에 서 작업 하고 
있으나 그것은 아직 완성되지 않은 상태에 있다. 

DPT 는 현재 몇년동안 지 원되 고 있는데 문제 점 은 배 치 구성프로그람을 실 행할수 있는 
DOS 나 SCO 를 요구한다는데 있 다. Linux 에 이 프로그람들을 이 식 하기 위 한 약속은 되 여 
있으나 아직 실현되지 않고 있다. DPT 는 필요한 정보를 제공하는 방법으로 Linux 를 지원 
하고 있는데 실제 작업 은 거 의 Michael Neuffer 에 의 하여 진행 되 고 있 다. 

DPT 는 다중통로조종장치 들과 캐 쉬장치 를 포함하는 몇 가지 좋은 특성 을 가지 고 있 다. 
여 기 에는 카드상에 들을수 있는 경 보기능뿐만아니 라 외부프로쎄스에 리용할수 있는 구동 
기 통지문도 있 다. 조종프로그람은 없지 만 RAID 배 렬 조종을 위한 간단한 프로그람과 관리 
기 가 써 넣 기 쉬 운 eTnail 도 있 다. 

ICP-Vortex 는 Linux 에 의하여 완전히 지 원되 며 배 치구성 을 위 하여 그 어 떤 다른 OS 
를 요구하지 않는다. 모든 ICP-Vortex 의 배 치 구성 은 카드의 BIOS 준위 에 서 실 현한다. 만 
일 배 렬안의 임의 의 디 스크들에 문제 가 생 길 때 체 계관리기 를 감시 하는 Linux 데 몬(묵인 
수속)이 있다. ICP 는 카드의 배렬을 리용할수 있는 여러개의 모형을 가지고 있는데 이 
카드들은 오직 RAID0 과 1 로부터 다중통로 RAID5 카드들로 구성될수 있다(지 어 빛섬유통 

로도). 

RAID0/1 카드는 만약 RAID5 에 대한 요구가 제기되면 RAID5 의 능력을 만족시킬 
수 있는 프로그람을 통하여 갱 신할수 있다. 모든 카드들은 72 핀 SIMM 소케 트를 거 쳐 
캐쉬를 추가할수 있는 능력을 가지고 있다 (EDO 와 표준 50ns SIMMs 는 둘다 잘 동작 
한다.). 

ICP-Vortex 는 오직 판본 2.0.33 에서만 지원되는 부족점 이 있다. 

SCSI 대 SCSI 조종장치 

SCSI 대 SCSI 해결방법은 여 러 가지 로 제 기되 고 있다. 례 하면 Mylex, CMD 그리 고 다른 
업체를 포함하는 많은 회사들로부터 해결방법들이 제기되고 있다. 이 방법들은 보통 외장 
시키는 방법 이며 조종장치의 케스안에 완전한 슬로트를 요구한다. 실제적관리부는 말단모 
방기 나 직 렬포구를 거 쳐 전면에 누르개단추들이 달려 있는 LCD 판을 통하여 실현된다. 어 
떤 모형들은 말단모방기는 직 렬포구중의 하나만을 가지며 또 어떤것들은 둘다 가지고 있 
다. 사용자들은 조종장치 자체 에 디 스크배 렬 을 설 정하며 조종장치 는 디 스크배 렬 을 한개 의 
론리장치 로 OS 에 준다(어 떻 게 설정하는가에 따라 한개 이 상의 론리장치 일수도 있 다.). 
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일반적으로 이 형태의 조종장치들이 가지고 있는 가장 큰 약점은 가격이 매우 비싼 
것 이 다. 

CMD 조종장치들은 Linux 프로그람이 관리를 목적으로 하는 장치들중의 하나에 불과 
하다. 이 장치 들은 2중여유림시교환조종장치 를 가진것 을 포함하여 리용가능한 여 러 가지 
모형 을 가지 고 있다. 만약 현재 있 는 하나의 조종장치 에 고장이 있 어 도 봉사기 를 멈 춰 
세 우지 않고 그것 을 교체할수 있 다. CMD 조종장치 는 또한 확장카드를 리 용하여 다중통로 
로 확장갱신할수도 있다. 많은 개발자들이 SCSI 대 SCSI 해결방법들을 제공하는데 여기서 
취 급한 내 용욤 오직 Mylex 를 가지 고만 해 본것 이 다. 

쏘프트웨어 RAID 

최종적 인 해결방법은 핵심부의 쏘프트웨 어 RAID 이 다. RAID 0과 1은 핵심부에 도입 
된지 퍽 오래 되 였 으며 검 사수정 들은 지 금 RAID 0~5를 지 원하는 2.0. X 핵 심 부에 리용되 
고 있는데 현재 2.2 핵 심 부에 서 표준으로 되 고 있 다. 쏘프트웨 어 RAID 는 장치체 계전반에 
대 하여 매우 빨리 검 사할수 있도록 개선되 였 다. 또한 임의의 블로크지원장치 로 사용할수 
있게 되여 있다. 이것은 한개의 디스크배렬에 正®나 SCSI 와 같은 장치들을 서로 섞어 리 
용할수 있다는것을 의 미하는데 현존 장치수준으로는 이것 이 완전히 불가능하다(사용자들 
이 요구한다는것은 의심할바 없지만 적어도 한개 장치를 분실하였거나 교체할것이 IDE 
장치 하나만일 때에 도움이 될수 있다.). 

기 본부족점 은 봉사기 가 RAID 의 기 우성계 산보다도 다른 함수계 산에 CPU 주기 들을 필 
요로 한다는데 있다. 쏘프트웨 에 IAID 의 가장 큰 우점은 가격 이 눅은것 이 다. 

쏘프트웨 어 RAID 는 현재 도 역 시 하나의 문제 점 을 가지 고 있는데 그것 은 뿌리파일 체 
계 에 대 하여 서 만 RAID 를 제 공하는것 이 다. 이 문제 는 체 계 를 기 동시 킬 수 있 는 기 동플로 
피디 스크나 혹은 작은 RAID 비 기 동구획 을 리용하여 극복할수 있 다. 

하지 만 그것을 실제 적장애 물로는 보지 않는다. 임의의 봉사기 는 어 떤 방법 으로 리용 
할수 있는 플로피디스크를 가지고 있으며 이 플로피디스크는 값이 눅고 못 쓰게 되는 경 
우에 쉽게 바끌수 있으므로 응용프로그람용의 완전한 기동매체로 되고 있다. 일단 2.2 핵 
심부가 리용가능하게 되 면(그리 고 안정한 상태 ) 사용자는 기 동플로피 디 스크나 소규모기 
동구획 혹은 어떤 다른 형식의 제거 가능한 매체 ( Zip 구동기， CD-ROM 등)를 리용하여 체 
계를 설치할 때 RAID 지원기능을 요구한다. 

여러가지 RAID 장치들은 단일한 실 패가능성을 제 거하여 일 정한 여유를 가지고 다양 
한 방법 으로 배 치구성 된 다. 배 치구성 은 장치적 인 가동환경，조작체 계，기 억관리프로그람 
혹은 특별한 장치 들에 의하여 설정될수 있다. Linux 의 경 우에 는 이 작업 이 구동기 들을 
통하여 실현된다. 

사용자는 실 현성 과 성 능을 높일 수 있도록 혼합된 배 치구성 방식 으로 RAID 를 리용할 
수 있 다. L 1 NUX 2.2. X 가 나온 이 래 RAID 구동기들은 모든 표준배포판들에 배포되 였다. 

RAID 의 기 술에 는 여 러 가지 준위 가 존재하는데 다음의것 들은 성 능과 실 현성，리용성 
이 좋은것들이다. 
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RAIDO 여 기 서 는 리 용성 이 기 본이 아니 며 디 스크가 RAIDO 으로 배 치 구성 되 는데 
이때는 파일들속에 I / O 를 련결할수 있도록 디스크를 통해 파일을 구획분 
할할 여유가 없다. 

RAID 1 RAID 준위 1은 보호를 제 공하는 첫번째 준위 이 다. 이 준위 는 사용자가 
두개 혹은 그이상의 디스크들을《거울》형식으로 쓸수 있게 하며 따라 
서 자료는 하나이상의 디스크전체에 걸쳐 재생되게 된다. 만일 한개 디 
스크가 고장나면 현재 리용되 는 RAID 체 계 는 고장난 디 스크를 쉽 게 피 하 
고 동작하는 디 스크들만 리용한다. 두개 의 디 스크들에 대 한 RAID 1 리용 
공간은 그 디스크들중의 하나의 크기와 같다(이것은 두 디스크가 같은 
크기 를 가지 는 경 우이 고 만약 서 로 크기 가 다르면 리용할수 있는 공간은 
정확히 두 디스크들중에서 작은것과 같다.). RAID 체계는 배렬의 모든 디 
스크사이 에 서 균형 읽 기 가 가능하므로 읽 기 상태 에 서 RAID 1 의 성 능은 좋 
아 진다. 하지만 쓰기성능은 그리 좋지 못하다. 왜 냐하면 전체 디스크에 
대하여 쓰기가 생겨야 하기때문이다. 이러한 성능은 디스크들에서 중요 
하게 읽기를 중시하기때문에(사실상 전체 시간의 95%정도 높다.) 많은 
체계(주로 파일봉사기형체계)들에서는 좋은 점으로 된다. 

RAIDO +1 RAIDO 의 구획 분할과 RAID 1 을 1대 1 거 울로 결 합한다. 따라서 이 기 술은 

고속성 과 리용성 을 다같이 높인 다. 

RAID 3 배 렬안의 한개 디 스크에 대 한 기 우성 정보를 기 억 하기 위한 여 유도를 제 
공한다. 이 기 우성 정보는 파괴 된 다른 디 스크상의 자료를 포함시키 는데 
도움을 줄수 있다. RAID 3 은 RAID 1 과 비교되는 정도의 기억을 디스크상 
에 보존하지 만 기우성디 스크가 병 목 ( bottleneck ) 현상에 빠질수 있기때 문에 
자주 쓰지는 않는다. 

RAID 5 RAID 3 과 류사한 여 유도로 기 우성 자료를 리 용하지 만 실제 적 인 자료를 구 

획 분할하는 방법 과 류사하게 모든 디 스크에 걸 쳐 기 우성자료를 구획분할 
한다. 이 방식 은 기 우성디 스크상에 서 병 목현상을 완화시 킨다. RAID 5 는 
아주 흔히 리 용된 다. RAID 준위 5는 자료리용성 과 성 능을 둘다 가장 좋 
게 절 충시 킨다. RAID 5 는 사용자가 적 어 도 3개 의 디 스크배 렬 을 생 성 할수 
있게 한다. 공간의 량은 일 반적 으로 전체 디 스크총량-1에 의하여 계산된 
다. 례 를 들어 4개 의 9 GB 디 스크를 리용할 때 사용가능한 공간의 크기 는 
3 X 9 GB 즉 27 GB 로 된다. 작은 여유무효공간이 있을수 있으나 그것은 제 
한되 여 있 다. RAID 5 에 의하여 자료는 전체 디 스크를 구획분할한 양식 에 
기 억 된다. 자그마한 차이 가 있 다면 역 시 기 우성 정보도 자료와 함께 구획 
분할된다는것 이 다. 따라서 어떤 디스크가 자기의 내용을 잃어 버리게 되 
면 아직 리용할수 있는 자료와 기 우성자료를 합하는 방법 으로 재 생성할 
수 있게 구획분할화가 리용되 기때 문에 성 능은 일 반적 으로 좋다. 쓰기성 
능은 기 우성발생 과 기 록용여유자료로 인하여 표준보다는 좀 뜨다. 읽 기 
성능은 읽기가 디스크들에 걸쳐 균형화되므로 좋다. 여러 디스크에 대하 
여 읽기할 때와 자료기지화된 자료나 기우성자료를 발생시키는 경우에 
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재생성되여야 할 자료와 같이 배렬이 디스크를 놓치는 경우에는 성능이 
현저히 떨어 진다. 그러나 결정적인 사실은 전체 디스크들이 모두 기능 
이 정지된다고 해도 자료는 여전히 살아 있다는것이다. 

RAID 6 을 비롯하여 보충적 인 RAID 준위들이 더 있다. 

RAID 6 은 2중기 우성 자료를 추가한것 이 며 RAID 7 과 RAID 8 은 RAID 5 의 특성 에 강화된 
성능을 보충한것들이 다. 

자료기 지 를 포함하는 봉사기 환경 이 나 직 결 거 래 처 리 ( OLTP ) 에 서 는 RAID 0+1 과 RAID 5 
가 혼합된 배 치구성 을 흔히 볼수 있 다. Linux 에 서 는 실제 적 으로 배 치구성 이 매 우 쉽다. 
Linux 환 경 에 서 는 RAID 를 실 현 하 기 위 하 여 두 개 파 일 즉 / etc/raidtab 와 / etc / 
rc . d / rc.local 만을 편집하면 된다. 이 개 념은 Linux 가 RAID 국부단위 로 분할디스크구획 에 접 
근하기 위한 특별한 구동기 즉 / dev/mdO 을 계공하는데 있다. 이 경 우의 인 상적 인 점 은 
RAID 환경에서는 분할구획들이 실제로 다른 디스크로 되여야 할 필요가 없다는것이다. 
대 다수의 경 우에 Linux 봉사기 상에는 한개 의 디 스크만이 포함되 여 있다. 새 롭고 좋은 점 
은 우리가 이 장에서 배운것을 이제 실현해 볼수 있다는데도 있다. 

RAID 의 설정 을 위한 단계 를 목록으로 보여 준다. 

▼ / dev/mdO 구동기 를 배 치 구성 한다. 

• RAID 환경 에서 구획들을 초기화하고 그것에 대하여 / etc/raidtob 에 통보한다. 

• / etc / rc . d / rc.local 에 서 RAID 동작을 자동적 으로 실 행 한다. 

▲ 올려태 우기점아래 에 RAID 구동기 를 올려태 우기한다. 

구획분할화 (striping) 

RAID 를 리용하는 근거 가 성 능이라면 RAID 0 (구획분할화)을 실현해 야 한다. 오직 한 
개 의 하드디 스크로 RAID 를 사람들이 안전하게 실현해 볼수 있게 하기 위하여 여 분의 구 
획 / dev / sda 3 과 / dev / sda 4 를 리용한다(이것은 우리 가 SCSI 디스크를 리 용한다는것을 의미 하 
며 그렇지 않은 경 우에 는 / dev / hda 3 과 / dev / hda 4 로 된다.). 

분명히 생성환경에서는 이것이 동일한 디스크나 조종장치에 대하여 서로 다른 RAID 
구획을 준다는 감을 전혀 주지 않는다. 

RAID0 배치구성 

RAID 0 을 배 치구성 하기 위하여 첫째 로 / etc/raidtab 에 RAID 0 환경 으로 설정하려 고 하는 
구동기와 구획에 대 하여 통보해 야 한다. 

/ etc/raidtab 아래에서 다음과 같은것을 볼수 있 다. 


raiddev 


dev/mdO 



chunk/size 4 

persistent-superblock 1 

device /dev/sda3 

raid-disk 0 


device 



/ dev/sda4 


일 단 우의 파일들이 정 확히 생성되 면 새 로운 RAID 디 스크들을 양식 화하여 야 한다 
(RAID0 은 성 능제 고를 위하여 여 러 디 스크사이 에 자료를 분배한다는데 대 하여 기 억 해 야 
한다. 물론 이 실례 에서는 두개의 구획 이 다같은 불리적디 스크에 있기때 문에 성 능상 리 
득은 없을것이다.). 

RAID 디 스크를 양식 화하기 위하여 다음의 조작을 실 행한다(명 백 히 root 에 관하여 ). 


mkraid/dev/mdO. 

다음 이 새 로운 론리디 스크상에 새 로운 ext2fs 파일 체 계 를 만든다. 즉 
mkfs -t ext 2 /dev/mdO 

마지막으로 기동시 에 RAID 구동기 가 자동적으로 동작할수 있게 /etc/rc.d/rc.local 에 한 
개 행을 보충하여 야 한다. 즉 


raidstart/dev/mdO 

이 제 새 로운 RAID 론리구동기 를 /op 任 선택 으로 올려태 우기하려 고 한다고 가정 하면 
우와 갈은 파일 에 다음의 행 을 추가한다(먼 저행 다음에 ). 


mount/dev/mdO / opt 2 

왜 이 행 을 보통 그것 이 속하는 / etc/fstab 에 설 정 하지 않는가? 

실제 적 으로 제 기 될 수 있는 문제 점 이 다. Linux 핵 심 부는 raidstart/dev/mdO 을 실 행 할 기 
회를 얻기전에 올려태우기하려 고 하므로 실패하게 된다. 이제 RAID 를 시 작할 때 체계를 
재 기동하지 않고 그것 을 올려 태 우기 하며 /etc/rc.d/rc.local 를 통하여 실행 되게 하기 위 하여 
다음과 같이 한다. 즉 


'Raidstart/dev/mdO 
mount/dev/mdO/Qpt 玄 

RAID1 배치구성 

RAIE)1 준위 를 설정하려 면 etc/raidtab 를 다음과 같이 편집한다. 
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/dev/mdO 
1 
2 
0 
4 

persistent-superblock 1 
device 
raid-disk 
device 
raid/disk 

실 행결과를 관찰하면 모든것 이 RAID- 준위 명 령 에 포함된다. 이제 다시 mkraid/dev/ 
mdO, mkfs ~t ext2/dev/md0 을 수행 하고 raidstart/dev/mdO 로 RAID 를 출발시 키 며 요구하는 
곳은 어디에나 이것을 올려태우기할수 있다. 속성예비디스크를 가진 RAID5 는 자료의 안 
전성 을 보장하는데서 상당히 쓸모 있는 객 체 라고 생 각한다. 실행 을 위한 모든 배 치구성 
후 프로그람을 제외하고 알맞는 etc/raidtab 를 아래에 보여 주었다. 


/dev/sda3 

0 

/ dev/sda4 


raiddev 

raid-level 


nr-spare-disks 

chunk-size 


raiddev 

raid-level 


nr-spare-disks 1 
parity-algorithm left-symmetric 
32 

/dev/sdal 


dev/sdc3 
2 

dev/sdd4 

3 

dev/sdel 

4 

dev/sdf1 


device dev/sdgl 

raid-disk 6 

# here come the spare-disk 
device /dev/sdhl 

spare-disk 
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RAID 으 I 한계 


RAID 는 좋은것 이 많은 반면에 일정한 제 한성 도 있다. 다시 강조하지 만 어 떤 종류의 
쏘프트웨 어 RAID 에 체 계등록부를 놓지 말아야 한다(특히/ boot 와 / usr ). 

기동시에 Linux 는 여전히 RAID 에 대하여 잘 알고 있지 못하며 따라서 제대로 초기 
화할수 없다. RAID 는 오직 자료디스크로 쓸것만을 권고한다. 

프로그람과 체 계파일들은 RAID 장치 에 속하지 않는다. 왜 냐하면 아주 중요한 
/ boot / sbin 과 / usr 등록부를 가지 고 작업 을 진행 하려 고 하면 좋지 않은 일 이 생 길수 있기 때 
문이 다. 사용자는 구획분할된 디 스크상에 서 거 울조작도 실 행할수 있 으나 그것 의 반대조 
작은 불가능하다. 따라서 여 러개의 디 스크상에 구획 을 나누어 줄수 있으며 그것의 꼭대 
기 에 거 울을 만들수 있 다. 하지 만 꼭 필 요되 는 일 이 라고 하더 라도 거 울자체 를 구획분할 
할수 없다. 

현재 가지 고 있는 한개의 디 스크로 RAID 1 의 절 반을 거 울로 설정할수 있으며 후에 
새 디스크를 얻으면 거기로 거울을 내려 놓을수 있다. 하지만 한 디스크의 내용을 다른 
디스크로 복사하는것과 그것들을 쌍으로 묶는것 이 아주 어 렵 기때 문에 그대 로 할것을 권 
고하지 는 않는다. 이 방법 을 실현하기 위 하여 서 는 우선 레 프라든가 혹은 세번째 디 스크 
의 자료를 여 벌복사하여 그것을 두번째 거울디스크가 추가된 다음에 회복하여 야 한다. 

또 다른 방법은 dev / null 로 두번째 RAID 1 을 정의하고 그다음 실제 디스크를 
etc / raidtab 의 두번째 디 스크로써 설 정 하는 방법 이 다. 두개 디 스크배 치 구성 을 위 한 RAID 1 
과 RAID 5 사이의 차이점은 무엇인가?(즉 두개 디스크밖의 RAID 1 배렬과 두개 디스크밖의 
RAID 5 배렬의 차이) 

기억용량에서는 아무런 차이도 없으며 용량을 증가시키기 위하여서는 매개 배렬에 
디 스크들을 추가할수 있 다(자세한 내 용은 아래 에 서 본다.). 

RAID 1 은 I / O 읽기에서 우월한 성능을 제공한다. 즉 RAID 1 구동기는 2개 쌕터 즉 매 
구동기 로부터 각각 하나씩 동시 적 으로 읽 을수 있는 분산-읽 기기 능을 리용하며 따라서 2 
중읽 기성 능을 발휘한다. RAID 5 구동기 는 여 러 가지 최 량적 수법 을 포함하지 만 실제 적 으로 
자료디 스크의 거 울복사로 되는 기우성디 스크를 실현하지 못하고 있다. 따라서 여기서는 
자료를 직렬로 읽는다. 


RAID 장치의 오유회복 

일부 RAID 알고리듬은 다중디스크오유에 대한 관측을 하고 있으나 현재 Linux 에서 
는 실현 하지 못하고 있 다. 그러나 Linux 쏘프트웨어 RAID 는 배렬의 득대기에 관하여 
배렬을 계층화함으로써 다중디스크오유에 대하여 관측할수 있다. 실례로 9개의 디스크 
로는 3개 의 RAID 5 배 렬을 만들수 있다. 이 3개 의 배 렬은 꼭대 기 로부터 단일 RAID 5 배 
렬을 호상 차례로 련결시켜 구성할수 있다. 사실 이런 형식의 배럴은 3개 디스크오유 
에 대 하여 관측할수 있다. 큰 디 스크공간은 여 유정 보에 관하여 《 랑비》된 다는데 대 하 
여 강조한다. 
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동작이 중지되지 않은 상태 에서 구획들은 다음상태들중의 어느 하나에 있을수 있다. 


▼ 기 억 디 스크의 캐 쉬 는 불확정 중지 가 발생 할 때 설 정 되 는 RAID 로서 sync 상태 에 있 
다. 잃 어 지는 자료는 없다. 

• 기 억디스크의 캐쉬는 폭주가 발생할 때 내용을 설정한 RAID 보다 더 새 롭게 갱 
신된다. 이것 은 파일체 계 가 흐트러 지 는 결과를 발생하며 잠재 적 인 자료들을 잃 
게 된다. 이 상태는 다음의 두개 상태로 더 나누어 진다. 

• Linux 는 불확정 중지 가 발생할 때 자료를 쓴다. 

• Linux 는 폭주가 발생할 때 자료를 쓰지 않는다. 

이 제 RAID1 배 럴 을 리용한다고 하자. 우의 두 경 우에 상태 는 폭주되 기 전 상태 일 수도 
있다. 이때 적은 수의 자료블로크들이 몇개의 거울들에만 성과적으로 씌여지며 따라서 
다음 재기동시에 거울에는 갈은 자료가 더 이상 포함되지 않는다. 만약 거울의 차이를 피 
하려고 했다면 RAID 구동기의 균형읽기코드는 자료읽기를 임의의 거울로부터 선택하며 
이 로부터 거 울들은 불일 치동작을 야기시키게 된다. 만일 RAID 구획 이 명백 히 올려태우기 
해제되지 않으면 fsck 가 실행되며 자체 로 파일체 계를 정돈한다. RAID 구획을 정 비하거 나 
혹은 회복하기 위 한 ckraic 卜 fix 명령도 있 다. 제일 좋기는 /etc/rc.local 상에 이 명령을 주어 
매번 체계가 기동할 때 이것을 실행시키는것이다. 이 조작은 /etc/rc.d/rc.local 에 다음과 
갈은 명 령행을 추가하는 방법 으로 실현할수 있다. 


mdadd / dev/mdO /dev/sdal /dev/sdcl 11 { 
ckraid 一一 fix /etc/raid.usr.conf 
mdadd/dev/mdO / dev/hdal / dev/hdcl 
} 


혹은 


mdrun -pi/dev/mdO 

if [$? -gt 0];then 

ckraid --fix/etc/raidl.conf 

mdrun -pi/dev/mdO 

fi 


기 정값에 의하여 ckraid-fix 는 첫 번째 동작거 울을 선택하며 그것 의 내 용으로 다른 거 
울들의 내용을 갱 신한다. 그러 나 폭주가 발생 하는 정 확한 시 간에 따라 다른 거울의 자료 
들이 더 갱신될수 있으며 그것을 원천거울로 대신 리용해도 된다. 

실례 1 . 

사용자에게 설정된(거울로 된) RAID1 이 있고 디스크 동작이 진행될 때 전원이 차단 
되였다. 


201 




mt . RAID 의 준위 여유도는 디 스크의 고장을 막을수 있게 설계되 였으나 전원고 
장에 대해서는 고려하지 못하였다. 이러한 상태에서 회복시킬수 있는 방법 
이 몇 가지 있다. RAID 배 렬 을 동기 화하는데 필 요한 RAID 도구들을 리용한 
다. 이 도구들은 파일 체 계 고장을 수리하지 는 못한다. RAID 배 렬 을 동기 화시 
킨 다 음 파 일 체 계 를 fsck 에 의 하 여 수 리 해 야 한 다 . RAID 배 럴 은 
ckraid / etc / raid . coiif ( RAIDl 에 대 하여 만일 아니 면 etc / raid 5 .conf 등을 리 용한 
다.)로 검 사할수 있 다. ckrai / etc / raidl . conf - fix 을 호출하여 배 렬안의 (보통 첫 번 
째 ) 디 스크들중에 서 하나를 끄집 어 내 여 기 본복사 (master copy ) 로 리 용하며 
그 블로크를 거울의 다른 블로크에 복사한다. 디스크들중의 어 느것 이 기 본 
디 스크로 사용되 여 야 하는것 을 지 적 하기 위 하여 -force - source 기 발을 리 
용할수 있다. 실례로 ckraid / etc / raidl.conf -fix -force - source / dev / hdc 3-§• 리 
용할수 있다. ckraid 명령은 아무런 변경도 주지 않고 비능동 RAID 배렬을 검 
증할수 있도륵 - fix 선택 항목이 없 이 안전하게 실행할수 있다. 제 기된 변경 
을 시켜도 일 없을 때는 - f lx 선택항목을 준다. 


실례 2. 


사용자에게 설정된 RAID 4 혹은 RAID 5( 기우성)가 있고 디스크동작이 진행될 때 전 
원이 차단되였다. 

해답. RAID 준위의 여유도는 디스크고장을 막을수 있게 설계되였으나 전원고장에 
대해서는 그렇게 되지 않는다. RAID 4 나 RAID 5 배렬의 디스크들이 fsck 가 
읽 을수 있 는 파일 체 계 를 포함하고 있지 않기때 문에 우의 항목이 보다 더 
적 다. 사용자는 예 비검사나 수리를 위하여 fsck 를 사용할수 없으며 반드시 
ckraid 를 우선 리 용해야 한다. ckraid 명령은 어떤 명령도 주지 않고 비 능동 
상태의 RAID 배 렬을 검증할수 있게 - fix 선택항목을 주지 않고 안전하게 실 
행시킬수 있다. 제기된 변경을 주어도 일없을 때는 -fix 선택항목을 준다. 
만일 요구되 면 “failed disk ” (고장난 디 스크)로써 디 스크들중의 어 느 하나 
를 지 적 할수 있 다. 이 조작을 위 하여 서 는 -suggest -failed -disk -mask flag 를 
수행한다. 기 발안에 서 한 비 트만이 설정 되 여 야 한다. RAID 5 는 고장난 디 스 
크 두개 는 회 복시키 지 못한다. 

여기서 마스크는 2진수비트마스크이며 다음과 같다. 

Oxl==first disk 
0x2==second disk 
0x4==third disk 
0x8==fourth disk, etc. 

한편 사용자는 suggest -fix - parity 기 발을 리 용하여 기 우성쌕 터 를 교정 하도록 선택 할 
수 있다. 이 조작에서는 다른 쌕 터들로부터 기우성을 다시 계산한다. 


202 



















extern inline int disk_spare (mdp_disk_t * d) 







{ 


d->state &= ~(1 « MD_DISK_SYNC) ; 


* MD * s 'extended* device 
*/ 

struct mdk_rdev_s 

{ 

struct md_list_head same_set;/* RAID devices within the same set */ 
struct md_list_head all; /* all RAID devices */ 

struct md_list_head pending; /* undetected RAID devices */ 


kdev_t dev; 


/* Device number */ 


kdev_t old 一 dev; 
unsigned long size; 
mddev_t *mddev; 
unsigned long last 一 events; 


/* " f, when it was last imported */ 

/* Device size (in blocks) */ 

/* RAID array if running */ 

/* 10 event timestamp */ 


struct block—device *bdev; 


/* block device handle */ 


mdp_super_t *sb; 
unsigned long sb_offset; 


int alias—device; 
int faulty; 
int desc_nr; 


/* device alias to the same disk */ 


/* if faulty do not issue 10 requests */ 
/* descriptor index in the superblock 


* disk operations in a working array : 

#define DISK0P_SPARE_INACTIVE 0 

#define DISK0P_SPARE_WRITE 1 

#define DISK0P_SPARE_ACTIVE 2 

#define DISK0P_H0T_REM0VE_DISK 3 

#define DISK0P_H0T_ADD_DISK 4 

typedef struct mdk_personality_s mdk_personality_t; 
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a disk inactive, but the disk is still part of the array) The interface 
to such operations is the 1 pers->diskop () 1 function, can be NULL. 


the diskop function can change the pointer pointing to the incoming 
descriptor, but must do so very carefully. (currently only 
SPARE—ACTIVE expects such a change) 

/ 

int (*diskop) (mddev_t *mddev, mdp_disk_t **descriptor, int state); 

int (*stop_resync 》 (mddev_t *mddev); 
int (*restart_resync 》 (mddev_t *mddev); 

int (*sync_request)(mddev_t *mddev, unsigned long block_nr); 


* Currently we index md_array directly, based on the minor 

* number. This will have to change to dynamic allocation 

* once we start supporting partitioning of md devices. 

extern inline int mdidx (mddev_t * mddev) 

I 



extern inline kdev_t mddev_to_kdev(mddev_t * mddev) 

{ 

return MKDEV(MD_MAJOR, mdidx(mddev)); 


extern mdk_rdev_t * f ind_rdev (mddev_t * mddev, kdev_t dev) ; 
extern mdk_rdev_t * fin d_r de v_n r (mdde v_t *mddev, int nr); 
extern mdp_disk_t *get_spare(mddev_t *mddev); 


iterates through some rdev ringlist. It's safe to remove the 
current 'rdev'. Dont touch 'tmp' though. 
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#define ITERATE—RDEV 一 GENERIC(head,field,rdev,tmp) 


\ 

\ 


for (tmp = head.next; 

rdev = md_list_entry (tmp, mdk_rde 
tmp = tmp->next, tmp->prev . 


_t, field), \ 
: &head \ 


* iterates through the 1 same array disks 1 ringlist 
*/ 

#define ITERATE_RDEV(mddev,rdev,tmp) \ 

ITERATE_RDEV_GENERIC((mddev) - >disks,same_set,rdev,tmp 》 


* Same as above, but assumes that the device has rdev->desc_nr numbered 

* from 0 to mddev->nb_dev, and iterates through rdevs in ascending order. 
*/ 

#define ITERATE_RDEV_ORDERED(mddev,rdev,i) \ 

for (i = 0; rdev = find_rdev 一 nr (mddev, i) , i < mddev->nb_dev; i++) 


* Iterates through all 'RAID managed disks * 

#define ITERATE_RDEV_ALL(rdev,tmp) \ 

ITERATE_RDEV_GENERIC(all_raid_disks,all,rdev,tmp 〉 


* Iterates through ’pending RAID disks 1 

#define ITERATE_RDEV_PENDING(rdev f tmp) \ 

ITERATE_RDEV_GENERIC(pending_raid_disks,pending,rdev,tmp 〉 


* iterates through all used mddevs in the system. 

*/ 

#define ITERATE_MDDEV(mddev,tmp) \ 

\ 

for (tmp = all_mddevs.next; \ 

mddev = md_list_entry (tmp, mddev_t, all_mddevs) , 
tmp = tmp->next , tmp-〉prev != &all_mddevs 
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return down_interruptible(&mddev->reconfig_sem); 


extern inline void unlock_mddev (mddev_t * mddev) 

{ 

up(&mddev->reconfig_sem); 

} 

#def ine xchg_values (x f y) do { _typeof_(x) _tmp = x; 

x = y; y = _tmp; } while (0) 

typedef struct mdk_thread_s { 

void (*run 》 (void *data); 

void *data; 

md_wait_queue_he ad_t wqueue; 

unsigned long flags; 

struct semaphore *sem; 

struct task_struct *tsk; 

const char *name; 

} mdk_thread_t ; 

#define THREAD_WAKEUP 0 

#define MAX_DISKNAME_LEN 64 

typedef struct dev_name_s { 

struct md_list_head list; 
kdev_t dev; 

char namebuf [MAX_DISKNAME_LEN]; 
char *name; 

} dev_name_t; 


#define wait_event_lock_irq(wq f condition, lock) \ 








제 7 장. 2차확장파일체계 

이 장 에 서 는 Linux 파 일 체 계 에 서 가 장 널 리 리 용 되 는 2 차 확 장 파 일 체 계 (Second 
Extended File System , ext 2 fs ) 에 대 하여 구체 적 으로 고찰한다. 

확장파일 체 계 의 기 본개 정 판은 Remy Card , Theodore Ts ' o , Stephen Twedie 에 의 하여 
서 술되 였으며 1993년 1월에 처 음으로 발표되 였다. 현재 이 체계는 Linux 에 의 하여 리 용 
되 고 있 는 유력 한 파일 체 계 이 다. 

이외에 NetBSD , FreeBSD , GNU HURD 와 Windows 95/98/ NT , OS /2 그리고 RISC OS 에 
리용할수 있 는 실 현 판들도 있 다. 

ext 2 fs 는 1 차 확장파일체계 (first Extended File System ) 에서 제기된 문제점을 수정하고 
강력한 파일체 계 를 제 공하기 위하여 설계 되 고 실현되 였 다. 이 파일체 계 는 UNIX 의 의 미 
론적방법 을 실 현하고 있 으며 보다 고급한 특성 들을 제 공하고 있 다. 

새로운 특성 

물론 설계자들도 역시 뛰여 난 성능을 얻기 위하여 ex 任 fs 를 요구하였으며 를퓨터를 
집중적으로 리용하는데서 자료가 루실될 위험성을 줄이기 위해서도 적응성이 좋은 파일 
체 계 를 요구하였 다. 

마지 막에 언급하겠지만 ext 2 fs 가 사용자로 하여 금 파일체계의 재양식화를 하지 않고 
도 새로운 특성으로 하여 리득을 얻을수 있도록 확장가능한 항목들을 포함해야 하였다. 

표준 ext 2 fs 의 특성 

ex 任 fs 는 표준 UNIX 파일형 식 들 즉 정 규파일，등록부，장치전용파일 그리 고 기 호적련 
결들을 지원한다. Ext 2 fs 는 실제적으로 큰 구획에 생성된 파일체계들을 관리할수 있다. 
초기의 핵심부코드는 파일체계의 최대크기 가 2 GB 로 제 한되 여 있었으나 VFS 층에서 동작 
하는 현재 파일체 계 는 4 TB 로 늘어 났다. 

따라서 지 금은 구획 을 많이 만들지 않고도 큰 디 스크들을 사용할수 있다. ext 2 fs 는 
255개 문자까지 긴 파일이름을 쓸수 있는 능력을 제공하고 있으며 여러가지 길이의 등록 
부입구점들을 사용할수 있다. 파일 이름의 한계는 필요한 경우 1012까지도 확장할수 있다. 
ext 2 fs 는 상위 블로크 ( root ) 를 위 하여 블로크의 5%까지 를 예 약하고 있기 때 문에 관리 기 로 
하여금 사용자프로쎄스들이 파일체계를 완전히 써버리는 경우에도 쉽게 회복할수 있다. 

개선된 ext 2 fs 의 특성 

표준 UNIX 의 특성외 에 ex 松 fs 는 일 반적 인 UNIX 파일 체 계 에 주어 져 있지 않는 많은 
확장성을 지원한다. 파일속성들은 핵심부의 동작이 파일모임우에서 진행될 때 사용자가 
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그것을 변경시킬수 있게 해준다. 

사용자는 파일 이 나 등록부상에 속성을 설정 할수 있다. 등록부에 속성을 설정 하는 경 
우에 그 등록부에 생성되는 새 파일들은 이 속성들을 계승해야 한다. BSD 혹은 System 
V Release4 의 의 미 론은 올려태 우기 시 에 설정된다. 

올려태 우기의 선택 은 관리기 가 파일생성의 미 론을 선택할수 있게 한다. BSD 의 의 미 
론으로 올려태 우기 된 파일 체 계 상에 서 파일 은 그것 의 선포등록부와 갈은 그룹 id (식 별 자) 
로 생 성 된다. System V 의 미 론은 좀더 복잡하다. 만일 등록부의 setgid 비 트가 설정되 여 있 
으면 새 파일은 그 등록부의 그룹 id 를 계승한다. 한편 부분등록부들은 그룹 id 와 setgid 
비 트를 계 승한다. 한편 파일 과 부분등록부들은 호출프로쎄 스의 원시그룹 id 를 가지 고 생 
성된 다. 

BSD 류형 의 동기 갱 신조작들이 ext2fs 에 서 리용될 수 있 다. 올려태 우기선택 은 관리기 로 
하여 금 메 타자료 (색 인마디，비 트매 프블 로크， 간접블 로크， 등록부블 로크) 를 그것 들이 변경 
될 때 디 스크상에 동기 적 으로 쓸것 을 요청하게 한다. 

이것은 엄밀한 메타자료의 일관성을 유지하는데 쓸모가 있지만 체계의 성능을 약화시키 
는 결과를 초래할수 있 다. 현실 에서 이 특성 은 일 반적 으로 리 용되 지 않으며 게 다가 메 타자료 
의 동기적갱신의 리용과 관련한 성능이 더 떨어 지기 때문에 사용자자료 즉 파일체계검사기 
에 의 하여 기 발에 표시 되 지 않는 자료에 헝 클어 짐 이 발생할수 있 다. 

ext2fs 는 또한 관리 기들이 파일체 계를 만들 때 론리 적 블로크의 크기도 선택할수 있게 
한다. 블로크크기 는 전형 적 으로 1024, 2048, 4096byte 로 될 수 있 다. 큰 블로크크기 를 리용 
하면 파일에 접근하는데 필요한 I/O 요청수가 더 적고 또 디스크머리부찾기수도 더 적어 
지기때문에 속도를 높일수 있다. 

달리 말하면 큰 블로크들은 더 많은 기억공간을 절약할수 있게 하며 평균적으로 파 
일에 배 정된 마지 막블로크는 절 반이면 된다. 따라서 블로크들을 더 크게 취 하면 더 많은 
공간이 절약된다. 

또한 보다 큰 블로크크기 를 리용하는데 서 주되 는 우점 은 ext2fs 파일 체 계 의 선행배 정 
기 술에 의하여 얻 어 진 다. 

마지 막으로 ext2fs 는 기 호련결을 고속화한다. 고속기 호련결은 파일체계 상의 임의의 
자료블로크들을 리용하지 못한다. 목적이름이 자료블로크에는 기 억되지 않고 색 인마디 자 
체 에 기 억된다. 이 방법은 배정되 여 야 할 자료블로크가 없기때 문에 일정한 디스크공간을 
기억할수 있으며 련결에 의하여 접근할 때에는 자료블로크의 읽기가 필요없으므로 련결 
연산의 속도를 높인다. 

물론 색 인마디 에 서 리용할수 있는 공간은 제 한되 며 따라서 매 개 련결은 고속기 호련 
결로 실현될수 있다. 고속기호련결에서 목표이름의 최대길이는 60 문자이다. 가까운 앞날 
에 파일들을 작게 할수 있도록 이 도식을 확장하기 위한 연구가 진행되고 있다. 기호련 
결들은 또한 색 인마디를 가지는 파일체계객체들이다. 련결들은 symlink 련결 이 60byte 보다 
작으면 그것들을 위한 자료가 색 인마디 자체안에 기 억되 기때 문에 특별히 강조하여 야 한다. 
색 인마디 는 자료기 억 을 위한 블로크에 대 한 지 적자를 보존하는데 표준적 으로 리용될수 
있는 마당들을 가지 고 있다. 이것 은 련결 이 블로크를 대 상하지 않도록 하기 위한 하나의 
최 량화이 다. 




등록 부 

등록부는 파일체계의 객체이며 파일과 갈은 색인마디를 가지고 있다. 등록부는 색인 
마디의 번호와 함께 매개 이름과 관련된 레코드를 포함하고 있는 특별히 양식화된 파일 
이다. 파일체계의 이후 개정판들도 역시 객체의 형 즉 파일，등록부，기호련결장치，대기 
렬 그리고 속도를 제고할 목적으로 등록부안의 소케트를 부호화하고 있다. ex 任의 실현판 
은 등록부안에 련결목록을 리용하고 있으며 계획적으로 성능을 높이기 위하여 B 나무를 
대 신 리용한다. 또 현재의 실현에서는 보다 큰 파일을 수용하기 위하여 등록부가 커지 기 
만 하면 그 등록부들을 절대로 줄이지 않는다. 

문자장치나 블로크전용장치들은 등록부로 지정되는 자료블로크를 포함할수 없다. 그 
대 신 블로크를 지 적하는데 리 용될 마당들을 다시 재 리용하여 색 인마디 에 장치번호를 기 
억 시 킨다. ex 任 fs 는 파일 체 계 의 상태 를 기 억 하고 있 다. 파일 체 계 의 상태 를 지 적 하기 위하 
여 핵 심 부코드가 상위블로크의 특정한 마당을 리용한다. 파일 체 계 가 읽 기/쓰기방식 으로 
올려태우기될 때 그것의 상태는 “Not Clean” 으로 설정된다. 또 읽기방식에서 올려태우 
기 해 제 되 거 나 재 올려 태 우기 될 때 에 는 상태 가 “clean” 으로 재 설정 된 다. 

기 동시 파일 체 계검 사기 는 파일 체 계 를 검 사해 야 되 겠는가 안해 도 되 겠는가를 결정하 
기 위하여 이 정 보를 리용한다. 핵 심 부코드도 역 시 이 마당에 오유를 기 록한다. 핵 심 부코 
드에 의하여 불일 치성 이 검 출될 때 파일체 계 는 “Erroneons” 로 표기된다. 

파일 체 계검 사기 는 상태 가 외 관상 명 백하게 보여 도 상관없 이 파일 체 계 의 검 사를 강하 
게 요구하기 위하여 이 마당을 검열한다. 때로는 파일체계검사를 건너 뛰는 경우가 있는 
데 이 조작은 위험할수 있기때 문에 ext2fs 는 정기적 인 간격으로 검사를 진행한다. 

상위블로크에는 올려태 우기계 수기 가 보존되 여 있다. 파일 체 계 가 읽 기/쓰기방식 으로 
올려태 우기 될 때 마다 이 계 수기 가 증가된 다. 이 계 수기값이 최 대 값에 도달하면(상위블로 
크에 기 록된) 파일 체 계 검 사기 는 파일 체 계 가 “Clran” 상태 에 있 다 하더 라도 검 사를 진행 
한다. 마지 막 검 사시 간과 최 대 검 사간격 도 역 시 상위 블로크에 기 억 된 다. 

이 두 마당은 관리기 가 주기적 인 검사를 요청할수 있게 한다. 최대검사간격 에 도달 
되 면 검 사기 는 파일체 계상태 를 무시 하고 파일체 계 의 검 사를 실행시 킨다. ext2fs 는 또한 
파일 체 계 의 동작을 조정 하기 위한 도구도 제 공한다. Tune2fs 프로그람은 다음과 갈은것 들 
을 변경시키 는데 리 용된 다. 

▼ 오유동작. 핵심부 코드에 의하여 불일치성이 검출되면 파일체계는 “Erroneous” 로 표 
식되며 다음의 3가지 동작중에서 어느 하나를 취한다. 즉 련속적 인 정상실행，파일체 
계 의 파괴 를 피 하기 위한 읽 기 전용방식 으로의 파일체 계재올려태 우기，파일체 계검 
사를 실 행 하기 위한 재 기 동 

• 최대올려태우기계수기 

• 최대검사간격 

▲ 상위블로크에 예약된 론리적블로크수 

올려태 우기 선택 (option) 핵 심 부오유동작을 변경 시 키 는데도 리용될수 있 다. 속성 은 사용 
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자가 파일에 관하여 안전한 지우기를 요청 하는데 리용된다. 파일이 지워 지면 우연자료 
( randomdata ) 가 파일에 이미 배정된 디스크블로크에 기록된다. 이것은 해커들과 디스크편 
집기를 리용하여 이미 있던 파일의 내용에 접근할 음흉한 목적을 가진 사람들로부터 체 
계 를 보호하는데 리 용된 다. 마지 막으로 4.4 BSD 파일 체 계 에 의 하여 시 사된 새 형 의 파일 체 
계들이 현재 ex 任免에 보충되고 있다는것을 강조해 둔다. 

불변파일들에 대 하여서는 읽 기만이 가능하며 쓰거 나 지우기는 할수 없다. 이 파일들 
은 예 민 한 배 치구성파일 들을 보호하는데 리용될 수 있 다. 

추가전용파일들은 쓰기방식 으로 열수 있는데 자료는 항상 파일의 끝에 첨 부된다. 불 
변파일들과 같이 이 파일들은 지울수 없고 이름을 재정의할수 없다. 이 파일은 특히 크 
기 가 커지 기 만 하는 가동일지파일들에 쓸모가 있다. 

■ 로크 

디스크나 파일의 공간은 블로크로 나누어 진다. 이 블로크들의 크기는 1024, 2048, 
4096 byte 로 고정되여 있다. 블로크의 크기는 파일체계가 생성될 때 결정된다. 보다 작은 
블로크일 수록 파일당 공간랑비 가 더 작아 진 다는것 을 알수 있지 만 대 신 휴지시 간이 더 
길어 지게 된다. 블로크들은 단편화되는것과 다량의 련속자료를 읽을때 머리부찾기회수 
를 줄이 기 위하여 블로크그름으로 클라스터화 ( cluster ) 하여 리용한다. 매 블로크그룹은 서 
술자와 상위블로크뒤에 직접 기억되는 서술자배렬을 가지고 있다. 

매 그룹선두의 두개 블로크는 블로크전용비트매프와 어느 블로크와 색 인마디가 리용되 
는가를 보여 주는 색인마디전용비트매프용으로 예약되여 있다. 매개 비트매프는 블로크와 일 
치되기때 문에 블로크그룹의 최 대크기는 블로크크기 의 8배 라는것을 알수 있다. 블로크그룹의 
첫 블로크(예 약되 지 않는)는 블로크용의 색 인마디 표를 가리 키 며 나머 지 는 자료블로크들이다. 

블로크배 정알고리 듬은 색 인마디 가 블로크그룹들을 포함하고 있 다는데 로부터 갈은 블 
로크내 에 자료블로크들을 배 정 하게 한다. 

예 약 공 간 

ext 2 는 특정 한 사용자(표준으로는 super - user ) 에 대 하여 일정 한 블로크수를 예 약할수 
있는 기능을 가지고 있는데 이 특정한 사용자는 체계로 하여금 어떤 사용자가 리용가능 
한 모든 공간을 다 채웠다고 해도 동작을 계속 할수 있게 해준다. 또한 완전히 공간을 다 
채운후에도 파일체계를 계속 보존하며 이것은 공간이 단편화되는것을 막을수 있게 한다. 

파일체계검사 

기 동시 에 대 다수 체 계 들은 파일 체 계 에 대 한 일 관성 검 사 ( e 2 fsck ) 를 진행 한다. ext 2 파일 
체계의 상위블로크는 기동시에 파일체계가 너무 크면 검사하는데 시간이 오래 걸리기때 
문에 실지 fsck 가 실행되는지 안되는지를 지적하는 몇개의 마당을 가지고 있다. fsck 는 
파일체 계 가 오유없이 올려태 우기 되거 나 혹은 최 대올려태 우기 계 수가 진행되 고 있거 나 혹 
은 검사들사이의 최대시간이 계측되고 있을 때 실행된다. 
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색인마디 

색 인마디(첨수마디)는 ext 2 파일체계 에서 기본개념 이 다. 파일체계에서 매 객체는 색 인마 
디 에 의하여 표현된다. 색 인마디구조체는 객체안에 보존된 자료와 그것의 이 름을 제외한 
객체에 관한 모든 메타자료를 포함하는 파일체계블로크들에 대한 지적자를 포함하고 있다. 

메 타자료는 허 가권，소유자，그를，기 발，범 위，사용된 블로크수，접 근시 간，변경시 간， 
수정시 간，지운시 간，련결수，단편수，관본 ( NFS 에서) 그리 고 ACL 들로 구성된다. 

색 인마디구조체 에는 현재 리용되지 않는 몇개의 예 약마당과 중복적재되 는 예 약마당 
들이 존재한다. 현재 마당은 색 인마디 가 한개 등록부이면 등록부 ACL 에 그리 고 색 인마 
디 가 정 규파일 이면 파일 크기 의 웃 32 bit 에 리 용된 다. 

변환마당은 Linux 에서는 리 용되지 않지 만 HURD 에서 이 객체 를 해석 하기 위 하여 리 
용될 프로그람의 색 인마디를 참조하는데 사용된다. HURD 는 또한 보다 큰 허 가권，소유 
자，그룹마당을 가지며 따라서 여 기서는 여유비트들을 기 억 하기 위하여 쓰이지 않는 몇 
개 의 다른 마당을 리용한다. 

색 인마디안의 파일자료를 포함하는 첫 12개 블로크에 대 한 지 적 자들이 있다. 또한 
다음블로크모임 을 지 적하는 지 적 자들을 포함하는 간접블로크지적 자와 간접블로크에 대 한 
지 적자를 포함하는 2중간접 블로크지적 자 그리 고 2중간접 블로크지적 자를 포함하는 3중간 
접 블로크지적 자가 있 다. 

기 발마당은 표준 chmod 기 발들에 의하여 제공되지 않는 몇개의 ex 任-전용기 발들을 포 
함한다. 이 기발들은 lsattr 로 목록화될수 있으며 chattr 명령으로 변경 시킬수 있 다. 여기에 
는 또한 지 우기，지 우기불가능，압축，동기 화갱 신，불변성，추가전용， dumptable , no - atime ， 
B 나무등록부기 능을 안전하게 실 행할수 있는 기 발들이 포함된 다. 

상우 I 블로크 

상위블로크는 파일체 계의 배 치구성 에 대 한 모든 정 보를 포함하고 있다. 상위블로크 
는 파일체계의 블로크 1(0 으로부터 번호를 매긴)에 기억되며 올려태우기하는데서 본질적 
요소로 된다. 상위블로크가 아주 중요하기때 문에 상위블로크의 여 벌복사는 파일체 계전반 
에 걸쳐 블로크그룹들에 기억된다. 

ext2 의 첫번째 개정판은 매개 블로크그룹의 시작에 복사판을 보관한다. 두번째 개정 
판은 대규모파일체계상에서 여유도를 줄일수 있도록 갈은 블로크그룹에만 복사판을 보존 
한 정의된 그롭은 0, 1과 3, 5, 7의 제곱으로 된다. 

상위블로크는 파일 체 계 에 색 인마디 와 블로크가 몇개 있 는가，그중에 서 몇 개 가 리용 
되지 않고 있는가，블로크그룹안에 몇개의 색인마디와 블로크가 있는가 그리고 언제 파 
일체계 가 올려태 우기되 였 으며 언제 수정되 였는가，파일체 계 의 판본은 얼 마이 고 어 느 OS 
가 생 성하였 는가와 같은 정 보를 포함하고 있 다. 

파일체 계 가 최근에 개정되 였으면 거기 에는 기록권이 름유일식 별자，색 인마디크기， 압 
축지원，블로크와 선행배 정 그리 고 상위블로크의 여 벌 복사를 적 게 할 필 요성 등이 포함 
된 다. 상위 블로크의 모든 마당(다른 ext2fs 구조체 에 서 와 같이 ) 들은 little endian 양식 으로 
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디스크에 기억되며 따라서 파일체계는 기계들사이에서 서로 이식될수 있으며 어느 기계 
가 그것을 생성했는가를 알 필요가 없다. 

개 정 

ext2 에 리용된 개정기술은 아주 정교하다. 

ext2 의 판본 0(EXT2-GOOD-OLD-REV) 에 의하여서는 지원되지 않지만 판본 1 에는 
도입되였다. 여기에는 3 개의 32bit 마당이 있는데 하나는 호환특성을 위한것이고 다른 하 
나는 읽 기 전용호환특성 을 위한것 이 며 또 다른 하나는 비 호환특성 을 위한것 이 다. 

■리적구조 

ext2 의 물리적구조에 강한 영향을 주는것은 BSD 파일체계의 형식이다. ext2 파일체계 
는 블로크그룹들로 구성되 였으며 이 그룹들은 BSDFFS 의 실 린더그룹과 류사하다. 하지 만 
현대 적장치 들이 순차접 근을 최 량화하고 있으며 그것의 물리 적공간형 식 을 조작체 계 로부터 
감추려 고 하고 있기때 문에 블로크그룹들은 디 스크상의 블로크들의 물리 적륜곽에 구애되 
지 않는다. 

파일체계의 물리적구조는 다음과 같다. 

BOOT BLOCK BLOCK … BLOCK 
sector Group 1 Group2 … GroupN 


매 블로크그룹은 아주 중요한 파일체계조종정보(상위블로크와 파일체계서술자)에 대 
한 예 비복사판을 포함하고 있으며 또 파일체 계의 다른 부분(블로크비트매프，색 인마디 비 
트매프，색 인마디표의 한 부분，자료블로크)도 포함한다. 

블로크그룹의 구조는 다음과 갈다. 

Super FS Block Inode Inode Data 

Block Description Bitmap Bitmap Table Block 

블로크그룹의 리용은 현실적 으로 아주 큰 우월성 을 가진다. 조종구조가 매 개 블로 
크그룹안에 복제되 기 때 문에 상위블로크가 손상될 때 파일체 계 로부터 쉽 게 복구할수 
있으며 이 구조는 또한 성능도 개선할수 있게 한다. 색인마디표와 자료블로크들사이 
의 거리를 줄임 으로써 파일 I 八)수행시 디스크선두탐색시 간을 줄일수 있게 한다. ext2fs 
에서 등록부들은 서로 다른 길이를 가진 입구점들의 련결목록으로서 관리된다. 매개 
입 구점 은 색 인마디번호，입구점길 이，파일 이 름，파일 이 름길 이를 포함한다. 가변길 이입 
구점 을 리용하여 등록부안에 서 기 억 공간을 랑비 하지 않고 긴 파일 이 름도 처 리할수 
沒다. 

등록부입구점의 구조는 다음과 갈다. 


Inode number entrylength namelength filename 
218 



례 를 들어 이 표가 세 개의 파일 즉 file , long _ file _ name , 松을 가지 는 등록부의 구조를 
표현한다면 다음과 같이 된다. 


il 

16 

05 

Filel 

i 2 

40 

14 

Long -file -name 

i 3 

12 

02 

松 


성능최량화 

ext 2 fs 핵심부코드는 성능최량화수법이 포함되여 있으며 이것은 파일의 읽기나 쓰기시 
에 FO 의 속도를 높인다. 

ext 2 fs 는 선행읽 기의 실행 에 의하여 캐쉬관리 에서 우월성 이 나타나고 있다. 블로크를 
읽어야 할 경우 핵심부코드는 여러개의 린접한 블로크들에 대하여 I/O 를 요청한다. 이것 
은 읽어야 할 다음 블로크가 이미 캐쉬에 적재되였는가를 확인하려는데 목적 이 있다는것 
을 의미한다. 선행읽 기는 보통 파일 에 대 한 순차읽 기 를 진행할 때 수행 되며 ext 2 fs 에서는 
이 것을 명백 한 읽 기 ( readdir (2)) 나 혹은 암시 적 읽 기 ( name : 핵 심부등록기 검 색)와 같은 등록기 
의 읽기로 확장하였다. 

ext 2 fs 는 또한 여러가지 배정최량화도 실현하고 있으며 블로크그룹들은 색인마디와 
자료와 관련되는 클라스터에 리용되며 핵심부코드는 항상 동일한 그룹의 파일에 관한 자 
료블로크들을 색 인마디 로 배 정하게 한다. 파일 에 대 하여 자료를 쓸 때 ext 2 fs 는 린 접한 
블로크를 8개 까지 선행 배 정 한다. 선행 배 정 적 중률은 완전히 채 워 진 파일 체 계 상에 서 도 거 
의 75%에 도달한다. 

이 선행배 정 방식 은 적 재 량이 많은 조건 에 서 높은 성 능을 가진다. 또한 이 방법 은 
련속된 블로크들을 파일로 배정할수 있게 하며 따라서 순차읽 기의 속도는 더 높아 지 
게 된다. 

이 두가지 배정최 량화에 대 하여 소개한다. 

▼ 관계되는 파일로부터 블로크그롭 

▲ 관계 되 는 블로크로부터 블로크배 정 을 위한 8 bit 무리짓 기 

메타-자료 ( meta - data ) 

ext 2 에 서 비 동기 적 메 타자료의 쓰기 방식 이 FFS 동기 적 메 타자료도식 보다 더 빠르지 만 
실 현성 이 적 다는데 대 하여 서 는 흔히 론의되 군 한다. 이 두 방법 은 각각의 fsck 프로그람으 
로 동일하게 해결될수 있다. 

메 타자료의 쓰기 를 동기 화하기 위한 방법 에 는 3가지 방법 이 있 다. 


▼ 원천을 가지고 있으면 매 파일당 처리 : open () 함수에 대하여 0_ SYNC 인수를 리용 
• 원천을 가지 고 있지 않을 때 매 파일 당 처 리 : chattr + s 리 용 
▲ 파일 체 계당 처 리 : mount-o sync 






첫번째 방법 과 세번째 방법 은 ext 2 에서 는 정의 되 지 않지 만 메 타자료를 동기적 으로 
쓸수 있다. 

ext 2 fs 서고 

ext 2 fs 서 고는 사용자방식프로그람이 ext 2 파일 체 계 의 조종구조체 를 조종할수 있게 개 
발되 였 다. 이 서 고는 물리 적장치 를 통하여 파일 체 계 에 직 접 접 근함으로써 ext 2 파일 체 계 상 
의 자료를 검 열 하거 나 수정하는데 리 용할수 있는 부분프로그람들을 제 공한다. 

ext 2 fs 서 고는 최 대 코드를 프로그람추상화기 술을 리 용하여 재 리 용할수 있게 한다. 실 
례 로 몇개의 서 로 다른 반복기 가 제공된다. 프로그람은 색 인마디안의 매 블로크를 호출 
하는 ext 2 fs _ block - interate () 에 한개 의 기 능으로 쉽 게 넘 길수 있 다. 다른 반복기 함수는 사 
용자제공함수가 등록부안의 매 개 파일을 호출할수 있게 한다. 

많은 ext 2 fs 편의 프로그람 ( Mke 2 fs ， e 2 fsck , tune 2 fs , dump 2 fs , debugfs ) 들은 ext 2 fs 서 고 
를 리용한다. 이것은 ext 2 파일체 계방식 에서의 새 로운 특성들을 반영 하기 위한 여 러 가지 
변화들이 한가지 장소 즉 ext 2 fs 서 고에 서 만 만들어 져 야 하기 때 문에 편의프로그람들의 유 
지보수성 이 매 우 단순해 진다. 이 코드들의 재 리용은 ext 2 fs 서 고가 공유서 고이 메 지 로 만 
들어 진다는데로부터 2진파일의 크기가 보다 작아 지게 한다. 

ex 任 fs 서고의 대면부가 아주 추상화되고 또 일반적이므로 ext 2 fs 파일체계에 직접 접근 
을 요구하는 새 프로그람은 읽기 가 아주 쉽다. 

실례 로 ext 2 fs 서 고는 4.4 BSD 를 포구에 dump 할 때 리 용되 며 또 편의 프로그람들을 복 
구할 때 리용된다. 이러한 도구들을 Linux 에 적응시키는데는 변경시킬 내용이 거의 없으 
며 극히 적은 체 계의존함수들만이 ext 2 fs 서 고의 호출에 의하여 바뀌워 져 야 한다. ext 2 fs 
서 고는 여 러개의 조작클라스의 접 근방법 을 제 공해 준다. 

첫번째 조작들라스는 파일체 계 지향조작들이다. 프로그람이 파일 체 계 를 열거 나 닫을 
수 있고 비 트매프자료를 읽거 나 쓸수도 있으며 또 디 스크상에 새 로운 파일체 계 를 생성할 
수도 있 다. 함수들은 또한 파일 체 계 의 불량블로크목록을 관리할수도 있 다. 

두번째 조작콜라스는 등록부에 영 향을 주는 클라스들이다. ex 任 fs 서 고 호출자는 등록 
부를 생 성 하고 확장할수 있 을뿐아니 라 등록부입 구점 을 첨 가하거 나 삭제할수도 있 다. 함 
수들은 색인마디번호에 대한 경로이름을 찾거나 색인마디번호가 주어 질 때 색인마디의 
경 로이 름을 결 정 하기 위하여 제 공된 다. 

마지막 조작콜라스를 리용하여 색인마디의 주사，읽기，쓰기 등이 가능하며 색인마디 
안의 모든 블로크들을 주사할수 있 다. 배정 과 배 정해제부분프로그람도 리용할수 있으며 
사용자방식 프로그람들의 블로크와 색 인마디 들을 배 정하거 나 해 제할수 있 다. 

ext 2 fs 도구 

ext 2 fs 에 리용되 는 강력한 관리 도구들이 개 발되 여 있 다. 이 편의프로그람들은 생 성 
및 수정 에 리 용되며 ext 2 파일체 계내 에서 임의의 불일 치성 을 교정하는데 리 용된다. 

mk 2 fs 프로그람은 빈 ext 2 파일 체 계 를 확보하기 위 하여 구획 을 초기 화하는데 리 용된 다. 
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tune 2 fs 프로그람은 파일 체 계파라메터 들을 변경 시키 는데 리 용된 다. 이 미 개 선된 ext 2 fs 
특성 에서 설명한것 처 럼 이 프로그람은 오유상태，최 대올려태우기계수값，최 대검사간격 그 
리 고 상위 사용자를 위하여 예 약된 론리 적 블로크들의 수를 변경 시 킬수 있 다. 그러 나 가장 
흥미 있는 도구는 아마 파일 체 계 검 사기 일 것 이 다. 

e 2 fsck 는 체계의 부정중지후에 파일체계의 불일치성을 해소시키는데 리용된다. e 2 fsck 
의 초기판본은 Minix 파일 체 계 를 위한 리 누스 토발즈의 fsck 프로그람에 기 초하고 있다. 
e 2 fsck 의 현재 판본은 ext 2 fs 서 고의 스크래 치 로부터 작성되 였 으며 초기판본보다도 훨 씬 
더 빠르고 파일체 계의 많은 불일치성 을 교정할수 있다. e 2 fsck 프로그람은 가능한대 로 빨 
리 실 행 할수 있 게 설 계 되 였 다. 파일 체 계 검 사기 들은 디 스크구역 성 을 지 향하기 때 문에 
e 2 fsck 에 의하여 리 용된 알고리 듬의 최 량화에 의하여 실현되 며 따라서 파일 체 계 구조체 에 
는 디스크로부터 반복적 으로 접근하지 못한다. 또한 색 인마디와 등록부가 검사된 순위는 
디스크찾기시간을 줄이기 위하여 블로크번호에 따라 정렬된다. 

통과 1에 서 e 2 fsck 는 파일 체 계안의 전체 색 인마디 에 걸 쳐 반복하며 파일체 계 의 비 련 
결객체에 관하여 매 색인마디를 검사한다. 이 검사는 다른 파일체계객체에 대하여 그 어 
떤 교차검사를 요구하지 않는다. 통과 1이 실행되는 기간 어느 블로크들과 색인마디들이 
사용중에 있는가를 지적하는 비트매프들이 콤파일된다. 만일 e 2 fsck 가 하나이상의 색인마 
디 가 자료블로크들을 요구한다면 매개 색 인마디가 공유블로크의 자체복사를 가지도록 공 
유블로크를 보조하거나 혹은 하나이상의 색인마디를 배정해제시키는 방법으로 이러한 모 
순을 해 결 하기 위하여 1 B 로부터 1 D 로 통과하게 된 다. 모든 색 인마디 들에 대 하여 기 억 으 
로의 읽기와 검사가 진행되여야 하므로 통과 1은 실행시간이 오래 걸린다. 다음 통과들 
에서 I / O 시 간을 줄이기 위하여 림계적 인 파일체계정보가 캐쉬 에 기 억된다. 

이 기술에 대한 가장 중요한 실례는 파일체계상의 모든 등록부블로크의 디스크우에 
서의 위치이다. 이 조작으로 하여 해당 정보를 얻는데서 통과 2가 실행되는 동안 등록부 
색 인마디구조체를 다시 읽어 야 할 필요가 없어 지게 된다. 

통과 2는 비 련결객 체 로서 등록부를 검 사한다. 등록부입 구점 들이 디 스크블로크들을 
련결하지 않기 때 문에 매 개 등록부블로크는 다른 등록부블로크를 참조하지 않고 개 별적으 
로 검사할수 있다. 이것은 e 2 fsck 가 모든 등록부블로크들을 블로크번호에 따라 정렬할수 
있게 하며 높아 지는 순서로 검사하기때문에 디스크찾기시간을 줄인다. 등록부블로크들 
은 등록부입 구점 들이 유효하다는것 을 확인하기 위하여 검 사되 며 또한 사용중에 있는 색 
인마디번호에 대한 참조값을 포함한다(통과 1에서 결정된것처럼). 

매 등록부색 인마디안의 첫 등록부블로크에서 과 입구점들은 현재 그것들 

이 존재한다는것과 입구점의 색인마디 번호가 현행등록부와 일치한다는것을 확인하 

기 위하여 검 사된다 ( 입 구점 에 대 한 색 인마디번호는 통과 3까지 검 사되 지 않는다.). 

통과 2에 서 는 또한 매 등록부가 련결된 상위등록부와 관련 이 있는 정 보를 캐 쉬 에 기 
억한다. 만약 등록부가 한개 이상의 등록부에 의하여 참조되 면 등록부에 대 한 두번째 참 
조는 부정확한 hard link 로 취급되여 제거된다. 

통과 2의 끝에서 e 2 fsck 의 조작수행 에 필요되는 모든 디스크 I / O 가 거의 완성된다는 
데 대하여 강조한다. 

통과 3, 4, 5가 요구하는 정보는 캐쉬에 기억되기때문에 e 2 fsck 의 나머지 통과조작들 


221 




은 CPU 에 크게 속박되고 전체 실행시간의 3~5% 보다 더 작아 진다. 

통과 3 에서 등록부의 련결성이 검사된다. e2fsck 는 통과 2 에서 캐쉬에 기억된 정보를 
리용하여 뿌리 까지 매 등록부의 경 로를 거 꾸로 추적한다. 

이때 입구점도 역시 유효성을 확인하기 위하여 검사되며 뿌리까지 거꾸로 추적 

할수 없는 임의의 등록부들은 /lost+found 등록부와 련결된다. 

통과 4 에서 e2fsck 는 색 인마디전체에 대하여 반복동작으로 모든 색 인마디들의 참조 
값을 검 사하며 통과 2 와 3 의 실행기 간에 계산된 내부계수값을 련결계수값(통과 1 에서 캐 
쉬에 기 억된)과 비교하는 방법으로 전체 색 인마디의 참조값을 검사한다. 

이 통과기간 련결계수값이 령인 지워 지지 않은 임의의 파일들은 역시 /lost+found 등 
록부에 련결된다. 

끝으로 통과 5 에서 e2fsck 는 파일체 계의 요약정보의 유효성을 검사한다. 검사는 블로 
크와 파일체 계 상의 실제 적비 트매 프에 대 하여 선행통과과정 에 구성된 색 인마디비 트매 프와 
비 교하는 방법 으로 실 현된 다. 또한 필 요한 경 우 디 스크상의 복사조작으로 수정한다. 

파일체계오유수정프로그람 (debuger) 도 또 하나의 쓸모 있는 도구이 다. 

Debugfs 는 파일 체 계 의 상태 를 검 열 하거 나 변화시 키 는데 리 용되 는 강력한 프로그람이다. 

기본적 으로 이 프로그람은 ext2fs 서고와의 호상작용대면부를 제공한다. 사용자에 의 
하여 건입력된 명령은 서고부분프로그람에 대한 호출로 변화된다. debugfs 는 파일체계의 
내부구조를 검열하는데 리용될수 있는데 손상된 파일전체를 수동적으로 복구하거나 혹은 
e2fsck 를 위 한 검 열 실례 를 생 성한다. 이 프로그람은 그것 이 무엇 을 하는지 모르는 사람들 
이 리 용하면 위 험할수 있 다. 왜 냐하면 이 도구를 잘못 리 용하여 파일 체 계 를 쉽 게 파괴할 
수 있기때문이다. 이런데로부터 기정값은 debugfs 가 파일체계를 읽기전용방식으로 열수 
있 게 설 정한다. 사용자는 debugfs 가 파일 체 계 를 읽 기/쓰기 접 근방식 으로 열 도록 하기 위하 
여 _ w 기 발을 명 백하게 정 의하여 주어 야 한다. 

2 차확장파일 체 계 는 Linux 용의 확장성 있 고 강력한 파일 체 계 로 연구되 였 다. 이 파일 
체계는 현재까지 Linux 계에서 가장 성과적인 파일체계이며 현재 발송되는 Linux 의 모든 
배포판들의 기초로 되는 체계이다. 많은 파일체계와 마찬가지로 ext2 파일체계는 파일에 
보존된 자료가 자료블로크에 보존된다는 전제 하에서 만들어 진다. 이 자료블로크는 모두 
길이가 갈으며 서로 다른 ext2 파일체계사이에서 그 길이가 변할수 있다 해도 특정한 ext2 
파일체계의 블로크크기는 블로크가 생성될 때 설정된다 (mke2fs 를 리용하여). 

매개 파일의 크기는 블로크옹근수로 둥그리기된다. 만일 블로크의 크기가 1024byte 이 
면 1025byte 짜리 파일은 2 개의 1024 짜리 블로크를 차지 하게 된다. 그러 나 이 것은 파일 당 
평 균적 으로 블로크가 절 반정 도 랑비 된 다는것 을 의 미한다. 보통 CPU 리용률을 계 산하는데 
서 타협할수 있는 기 준은 기 억과 디 스크의 공간리용성 이다. 대 다수 조작체 계 와 함께 
Linux 의 경 우에 도 CPU 의 작업 부하를 줄이 기 위하여 무효한 디 스크의 리용을 상대 적 으로 
제 한하고 있다. 파일체 계 에서 모든 블로크들이 다 자료를 보존하는것 이 아니 라 그중 몇 
개는 파일체계의 구조를 표현하는 정보를 보관하는데 리용된다. 

ext2 는 파일 체 계 의 매 파일 을 색 인 마디자료구조로 서 술하여 파일 체 계 의 기 하학적모 
양을 정 의한다. 색 인마디 는 파일안의 자료가 어 느 블로크를 차지 하고 있는가를 서 술할뿐 
아니 라 파일 의 접 근권한，파일 의 변경시 간 그리 고 파일의 형 도 서 술한다. ext2 파일 체 계 에 
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색인마디는 다음에 설명하는 마당들을 포함한다. 


방 식 

방식은 두개의 정보단위 즉 색인마디가 무엇을 서술하는가와 사용자가 거기에 보존 
해 야 할 허 가권을 기 억한다. ext2 에서 색 인마디 는 파일，등록부，기 호련결，블로크장 
치，물리장치，대기렬 등을 서술할수 있다. 

소유자정보 

이 마당은 파일 이 나 등록부소유자들에 대 한 사용자와 그룹의 식별자들을 포함한다. 

크 기 

바이트수로 정의되는 파일의 크기 

시간표식 

색인마디가 생성된 시간과 그것이 변경된 마지막시간 

자료를로크 

색인마디가 서술하고 있는 자료를 포함하는 블로크에 대한 지적자들중 첫 12개는 
색 인마디 에 의 하여 서 술된 자료를 포함하는 물리 적 블로크들에 대 한 지 적 자이 며 마 
지막 3개 지 적 자는 보다 더 높은 간접준위 를 포함한다. 실례 로 2중간접 블로크지적 자 
는 자료블로크를 지 적하는 블로크지적 자에서 지적된다. 이것은 자료블로크의 길 이 
가 12보다 작거나 같은 파일들이 그것보다 큰 파일들보다 더 빨리 접근한다는것을 
의 미한다. ext2 색 인마디 들은 전용장치파일 들을 서 술할수 있는데 이 장치파일 들은 실 
지 파일은 아니고 프로그람들이 장치에 접근하는데 사용될수 있는 핸들(조종자)이라 
는데 대하여 강조한다. 

/dev 안의 모든 장치 파일들은 프로그람들이 Linux 의 장치 에 접근하게 한다. 실례 로 올 
려태 우기프로그람은 올려태 우기해 야 할 장치 를 한개 의 인수로 취 한다. 

ext 2 fs 의 상우 I 블로크 

상위블로크는 파일체계의 기본크기와 모양을 서술한다. 상위블로크안에 있는 정보는 
파일체계관리기가 파일체계를 관리하고 리용할수 있게 한다. 보통 체계가 올려태우기될 
때에는 블로크그룹 o 에 있는 상위블로크만을 읽지만 매 블로크그룹은 파일체계가 손상되 
는 경우에 2중복사본을 포함한다. 

상위블로크는 다음과 갈은 정 보들을 포함한다. 

매지크번호 

매지크 (magic) 번호는 프로그람올려태우기동작시 해당 프로그람이 실지로 ext2 파일체 



계 의 상위블로크 인 가를 검 사하는데 리 용된다. 현재 의 ext2 판본에 서는 이 값이 
OxEF53 이 다. 


개정준위 

기 본개 정준위 와 부차개 정준위 는 올려태 우기코드가 파일체 계 지원특성 을 파일 체 계 의 
특정한 개정준위 에서만 리용할수 있는가에 대 하여 판정할수 있게 한다. 여 기 에는 올 
려태 우기코드가 현재 파일체 계 에서 어 떤 새 로운 특성 을 안전하게 리용할수 있는가 
를 결 정하게 하는 특성호환마당들이 있 다. 

올려태우기계수값과 최대올려태우기계수값 

파일체 계 가 완전히 검 사되 였는가를 결정하는데 이 정 보들을 리용한다. 올려태 우기 
계수값은 매 번 체계 가 올려태우기될 때 마다 증가되 며 그 계수값이 최대올려태우기 
계 수 값과 같아 지 면 경 고통보 문 “ maximum mount count reached, running e2fsck is 
recommended” 를 연시 한다. 

를로크그룹번호 

상위 블로크의 복사를 보존하고 있는 블로크그룹의 번호이다. 

를로크크기 

바이트수로 표시되는 파일체계에서 블로크의 크기. 실례로 1024byte 이다. 

그룹당 M 로크수 

그룹안에서의 블로크수는 블로크크기와 마찬가지로 파일체계가 생성될 때 고정된다. 

자유 M 로크 

파일 체 계 안의 자유색 인마디 들의 수이 다. 

첫번째 색인마디 

파일체계안의 첫번째 색인마디의 번호. ext2 뿌리파일체계에서 첫번째 색인마디는 
“/ ” 등록부에 대한 입구점들로 된다. 

ext 2 그룹서술자 

매개 블로크서 술자들은 그것을 서술하는 자료구조체를 가지고 있 다. 상위 블로크에서 
처 럼 모든 블로크그롭들에 관한 전체 그룹서술자는 파일체계가 파손될 때 매개 블로크그 
룹에 복제된다. 매개의 그룹서술자는 다음정보를 포함한다. 


M 로크비트매프 
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블로크그룹에 대한 블로크배정 비트매프의 블로크번호이다. 이것은 블로크의 배정 
및 배정해제시에 리용된다. 

색인마디비트매프 

블로크그룹에 대 한 색 인마디배 정 비 트매 프의 블로크번호이 다. 역 시 색 인마디 의 배정 
과 배정해제에 리용된다. 

색인마디표 

해당 블로크그룹의 색인마디표에 대한 출발블로크의 블로크번호이다. 매 색인마디는 
아래 에 서 술한 ext 2 색 인마디 자료구조체 에 의 하여 서 술된 다. 

자유블로크계수，자유색인 마디계수, 리용된 등록부계수 

그롭서 술자가 차례 로 배 치 되 여 그룹서 술자표를 구성한다. 매 블로크그룹은 전체 그 
롭서 술자표를 포함하며 그뒤 에 상위 블로크의 복제 부분이 포함된 다. 

첫번째 복사부분(블로크그룹 0의)만이 실제 적 으로 ext 2 파일체 계 에서 리 용된다. 기 본 
복사부분이 손상된 경우에 상위블로크의 복사부분과 같이 다른 복사부분들은 거기에 남 
아 있게 된다. ext 2 파일체 계 에서 등록부들은 파일체 계안의 파일 에 대 한 접근경 로를 생성 
하고 유지하는데 리용되는 특별한 파일이다. 등록부파일은 매개가 다음정보를 포함하 
고 있는 등록부입구점들의 목록이다. 

색인마디 

등록부입구점에 대한 목록이다. 이것은 블로크그룹의 색인마디표에 기억된 색인마디 
배렬첨수이다. 실례로 “ file ” 이라는 이름을 가진 파일에 대한 등록부입구점은 색인 
마디번호 il 에 대한 참조값을 가지고 있다. 

이름길이 

바이 트수로 표시되는 등록부입구점 의 길이 이 다. 

이 ■ 

등록부입구점의 이름이다. 매 등록부의 첫 두개의 입구점은 항상 “this directory ” 
와 “parent directory ” 를 의 미 하는 표준 과 입 구점 이 다. 

ext 2 과일체계에서 과일의 크기변경 

파일체계에서의 공통적인 문제점은 그것의 토막화경향성이다. 파일의 자료를 보관하 
는 블로크들이 파일체계전반에 널리 퍼져 자료블로크들사이의 거리가 멀어짐으로써 파일 
자료블로크에 대 한 순차적접 근은 점 점 더 어 려 워 지 게 된 다. ext 2 파일 체 계 는 이 문제 를 
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현재 자료블로크들과 물리적으로 가까운 파일 혹은 적어도 갈은 블로크그룹에 새 블로크 
를 배정하는 방법으로 극복하고 있다. 이것이 실패할 때에만 다른 잠금그룹에 자료블로 
크를 배 정한다. 어 떤 프로쎄 스가 파일 에 자료를 쓰러 고 할 때 마다 Linux 파일 체 계 는 자료 
가 파일의 마지 막 배정블로크의 끝에서 제거되 였는가를 알아 보기 위하여 검사를 진행한 
다. 만일 제거되 였 다면 파일 에 새 로운 자료블로크를 배정해 야 한다. 배정 이 완료될 때 까 
지 프로쎄 스는 실 행 될 수 없 다. 프로쎄 스는 새 로운 자료블로크를 배 정 하기 위하여 파일 체 
계를 기다려야 하며 그것을 계속하기에 앞서 자료블로크에 자료의 나머지를 써넣어야 한 
다. ext 2 블로크배 정프로그람이 실행하는 첫 번째 과제 는 파일체 계의 ext 2 상위 블로크를 잠 
그는것 이 다. 배 정 과 배 정 해 제 는 상위 블로크안의 마당들을 변화시 키 는데 Linux 파일 체 계 는 
하나이 상의 프로쎄 스가 동일 한 시 간에 이 동작을 수행하게 할수 없 다. 만일 다른 프로쎄 
스가 더 많은 자료블로크를 배정하려고 한다면 해당 프로쎄스가 완료될 때까지 대기해야 
할것 이 다. 상위 블로크를 기 다리 는 프로쎄스는 중단되 며 상위블로크의 조종이 현행사용자 
에 의하여 제거될 때 까지 실행할수 없다. 상위블로크에 대 한 접근은 먼저 온 객체 에 게 
먼 저 봉사하는 방식 에 기 초하여 부여되 며 일 단 프로쎄 스가 상위블로크의 조종에 착수하 
면 완료될 때 까지 조종을 계 속한다. 상위블로크의 잠금이 완료된 후 프로쎄 스는 파일 체 계 
에 자유블로크가 충분히 남아 있는가를 검사한다. 자유블로크가 충분하지 못하면 배정을 
더하려 던 과정 은 실패하며 프로쎄스는 파일 체 계 상위 블로크의 조종을 철회한다. 만약 자 
유블로크가 충분하게 있 으면 프로쎄 스는 그것 을 배 정하게 된 다. ext 2 파일 체 계 가 자료블로 
크들을 선행 배 정할수 있게 구성 되 여 있으면 그 블로크들중의 어 느 하나를 사용할수 있다. 
선행배정된 블로크들이 실제적 으로 존재하지 않으면 배정된 블로크비트매 프안에 예 약된 
다. 자료블로크를 배 정하려 고 하는 파일 을 표현하는 VFS 의 색 인마디 는 두개 의 ext 2 정 의 
용마당 prcalloc _ block 와 prealloc _ count 를 가지 고 있는데 이 것 들은 각각 첫 번째 선행 배 정 
자료블로크번호와 그것들의 개수이 다. 선행배정된 블로크가 전혀 없거 나 블로크선행배 정 
이 불가능하면 ext 2 파일체 계는 새 블로크를 배정해 야 한다. ext 2 파일체 계 는 우선 파일안 
에 새 자료블로크가 비여 있는가를 알아 본다. 론리적으로 이것은 순차접근을 더 빨리 
실현할수 있기때문에 배정에서 제일 효과적인 블로크로 된다. 이 블로크가 비여 있지 않 
으면 람색공간을 더 넓 혀 리 상적 으로 64개 블로크내 에 서 자료블로크를 찾는다. 리 상적 이 
아니라고 해도 이 블로크는 아주 가까이에 있으며 적어도 파일에 속하는 다른 자료블로 
크들의 같은 블로크그룹내 에 있 다. 만약 다음 블로크가 비 여 있지 않으면 프로쎄스는 여 
러개의 자유블로크들을 찾을 때 까지 차례 로 다른 모든 블로크그룹들을 찾기 시 작한다. 
블로크배정코드는 한개의 블로크그룹안의 어디에서든지 8개의 빈 자료블로크의 무리 짓 
기 ( cluster ) 를 찾아 낸 다. 만약 8개 를 동시 에 찾지 못하면 적 은 량이 라도 받아 들인 다. 또 
한 블로크선행배정이 요구되고 가능하면 prealloc _ block 와 prealloc _ count 를 적당히 갱신한 
다. 자유블로크들을 찾아 낼 때 마다 블로크배 정코드가 블로크그룹의 블로크비 트매 프를 
갱 신하며 캐 쉬 에 자료완충기 를 배 정한다. 이 자료완충기 는 파일 체 계 가 지 원하는 장치식 
별자와 배 정된 블로크의 블로크번호에 의하여 일의 적 으로 식 별된다. 



완충기안의 자료는 값이 령이며 이때 물리적디스크에 씌여 지지 않은 내용이라는 
것 을 보여 주기 위하여 “ dirty ” 라고 표식 을 단다. 끝으로 상위블로크 그자체 도 변경 
되 지 않고 잠금이 되 지 않았다는것 을 보여 주기 위하여 “ dirty ” 로 표시한다. 만일 
상위블로크를 기 다리 는 어 떤 프로쎄 스들이 있을 때 는 대 기렬의 첫번째 프로쎄 스에 대 
하여 실행이 다시 허용되며 파일의 조작과 관련한 배타조종이 이루어 지게 된다. 프 
로쎄스의 자료는 새 자료블로크에 기록되며 만일 자료블로크가 채워 져 있으면 전체 
프로쎄 스가 반복되 여 다른 자료블로크가 배정된다 .이 부분에 서 는 상위블로크의 배 치 
구성을 서술한다. 

아래 의 내 용은 ext 2 fs 상위 블로크 [ include / linux / ext 2_ fs . h ] 의 공인된 구조체 이 다. 


struct ext2_super_block{ 


unsigned long 
unsigned long 
unsigned long 
unsigned long 
unsigned long 
unsigned long 
unsigned long 
long 

unsigned long 
unsigned long 
unsigned long 
unsigned long 
unsigned long 
unsigned short 
short 
unsigned short 
unsigned short 
unsigned short 
unsigned short 
unsigned long 
unsigned long 
unsigned long 


s_inodes_count; 
s_blocks_count; 


s_r_blocks_count; 


s_f ree_blocks_count; 
s_free_inodes_count; 
s_f irs t_data_b lock; 
s_l o g_b loc k_s ize; 



s_block_per_group; 
s_f rags_per_group; 
s_inodes_per_group; 



s_mnt_count; 


s_max_mnt_count; 


s_magic; 


s_state; 


s_errors; 

s_pad; 

s_lastcheck; 
s_checkinterval; 
s_reserved[238] ; 


아래에 몇가지 설명을 준다. 
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시간들은 1970.1.1 GMT 00 : 00 : 00으로부터 초단위로 측정된다. 

일단 상위블로크가 기억에 적재되면 ext 2 fs 핵심부코드는 일련의 다른 정보들을 계산 
하며 그것을 다른 구조체 에 보존한다. 

이 구조체는 다음의 형식을 가전다. 

struct ext_sb_info{ 

unsigned long s_frag_size; 
unsigned long s_frags_per_block; 
unsigned long s_inodes_per_block; 
unsigned long s_frags_per_group; 
unsigned long s_b1ock_per_group; 
unsigned long s_inodes_per_group; 
unsigned long s_itb_per_block; 
unsigned long s_groups_count; 
struct buffer_head * s_sbh; 
struct ext2_super_block*s_es; 

structbuffer_head *s_group_desc[EXT2_MAX_GROUP_ 

DESC]; 

unsigned short s_loaded_inode_bitmap; 

unsigned short s_loaded_block_bitmaps; 

unsigned long s_inode_bitmap_number [EXT2_ 

MAX_ GROUP_LOADED]; 

struct buffer_head *s_block_bitmap[EXT2_ 

MAX_GROUP_LOADED ] ; 

unsigned long s_b 1 ock_bitmap_number 

[EXT2 - MAX_GROUP_LOADED] ; 
int s_rename_lock; 

struct wait_queue *s_rename_wait; 

unsigned long s_mount_opt; 

unsigned short s_mount_state; 

}； 

구조체의 성분들에 대한 설명을 다음에 준다. 
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start ext2_group_desc 
{ 

unsigned long bg_b1ock_bitmap; 
unsigned long bg_inode_bitmap; 
unsigned long bg_inode_table; 
unsigned long bg_free_block_count; 
unsigned long bg_free_inodes_count; 
unsigned long bg_used_dirs_count; 
unsigned long bg_pad; 
unsigned long bg_reserved[3]; 

}； 


여기서 이 구조체의 몇가지 성분들에 대하여 설명한다. 


bg_block_bitmap 

그롭에 관한 블로크비트매프블로크를 지적 

bg_inode_bitmap 

그롭에 관한 색 인마디 비트매프블로크를 지적 

bg_inode_table 

색 인마디표의 첫 블로크 지적 

bg_f ree_inode_count 

그룹안의 자유블로크수 

bg_f ree_inode_count 

그룹안의 자유색인마디수 

bg_used_dirs_count 

그롭안의 등록부에 배정된 색인마디수 

bg_pad 

패딩 


그룹서술자내의 정보는 오직 그것이 서술하고 있는 그룹에만 실제적으로 관련된다. 

비트 매프 

ext 2 파일체 계는 배정된 블로크들과 색 인마디의 위 치를 항시적 으로 탐색 하기 위하여 
비 트매 프를 리용한다. 매 그룹의 블로크비 트매 프는 그룹안의 첫 블로크로부터 마지 막블 
로크사이의 범위 에 있는 블로크들을 참조한다. 정 확한 블로크의 비 트로 접근하기 위하여 
먼저 블로크가 속하는 그룹을 찾고 다음 그 그룹에 포함되는 블로크비트매프의 블로크비 
트를 찾는다. 사실 블로크비 트매 프가 파일 체 계 에 의하여 지 원되 는 가장 작은 배 정단위 를 
토막 ( fragment ) 이 라고 간주하는것은 아주 중요한 리해 로 된 다. 블로크크기가 항상 토막크 
기 들의 중복으로 이루어 지 기때 문에 파일체계관리기 는 블로크를 배정할 때 실제적 으로 
다중화된 개 수의 토막을 배 정한다. 이 블로크비 트매 프의 리용은 파일 체 계관리기 로 하여 
금 토막에 기 초하여 공간을 배 정하거 나 배 정해제할수 있게 한다. 매 그룹색 인마디비 트매 
프는 그룹의 처음부터 마지막색인마디까지의 범위에 있는 색인마디들을 참조한다. 정확 
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한 색 인마디의 비트에 접근하기 위 하여 먼저 색 인마디 가 속한 그롭을 찾고 다음에 그 그 
룹안에 포함된 색 인마디 비 트매 프의 색 인마디 비 트를 찾는다. 색 인마디 표로부터 색 인마디 
정 보를 얻 는 방법 은 마지 막탐색 이 색 인마디 비 트매 프대 신 그룹색 인마디 표에서 진행된 다는 
것을 제 외 하고는 토막에 대 하여 진행 하는 방법 과 곡 갈다. 

색인마디 

색 인마디는 파일을 유일적으로 서술한다. 

색인마디구조체의 형식을 아래에 보여 주었다. 


unsigned short i_mode ; 
unsigned short i_uid; 


unsigned long 


unsigned long 


unsigned long 
unsigned long 
unsigned long 
unsigned short 
unsigned short 
unsigned long 
unsigned long 
unsigned long 
unsigned long 
unsigned long 
unsigned long 
unsigned long 
unsigned long 
unsigned char 
unsigned char 
unsigned short 
unsigned long 
}; 



i_dtime; 

i_gid; 

i_links_count; 



i_f lags; 

i_reservedl; 

i_block [ext2_n_blocks ] ; 




i_faddr; 
i_frag; 
i_f size; 
i_padl ; 

i_reserved2[2]; 


몇가지 구조체성분에 대하여 서술한다. 
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그 time 

파일의 색 인마디정보가 변경된 마지막시간 

ntime 

파일내용을 변경시킨 마지막시간 

itime 

파일이 지워 질 때 

jid 

파일의 gid 

Links_count 

이 파일 을 지 적하는 련결의 수 

)lock 

512 byte 단위로 계수되는 파일에 배정된 블로크의 수 

flags 

기발(아래를 볼것) 

reservedl 

에 약 

)lock 

블로크에 대 한 지적 자(아래를 볼것》 

/ersion 

파일의 판본 ( NFS 에서 리용) 

Eile_acl 

파일의 접근조종목록(아직 리용되지 않음) 

iir_acl 

등록부의 접근조종목록(아직 리용되지 않음) 

Eaddr 

파일의 토막들이 존재하는 블로크 

size 

토막의 크기 

)adl 

패딩 

reserved 2 

에 약 


보는바와 같이 색 인마디는 블로크에 대 한 EXT 2_ N _ BLOCKS ( ext 2 fs 0.5 에서는 15) 지적 
• 포함하고 있다. 이 지적자들중에서 첫 EXT 2_ N _ BLOCKS (12) 는 자료에 대한 직접지 
이다. 

다음의 입 구점 은 자료에 대 한 지 적 자들의 블로크를 지 적한다(간접 ). 그 다음의 
•점 은 자료에 대 한 지 적 자들의 블로크에 대 한 지 적 자블로크를 지 적 한다 (2 중 
)• 

다음입 구점 은 자료지적 자블로크에 대 한 지 적 자들의 블로크를 지 적하는 지 적 자블로크 
적 한다 (3 중간접 ). 

색 인마디기 발들은 다음과 갈은 하나이 상의 론리합을 취 함수 있 다. 

EXT2_SECRM_FL .0x0 001 

안전한 지우기 이 조작은 보통 이 기발이 설정될 때 파일을 지운다는것을 의 
미한다. 우연자료가 파일 에 이미 배 정된 블로크들에 씌 여 질수 
있 다. 


EXT 2_© KftBO *: L _0 x 0 0 02 

지우기해제 이 기 발이 설정되 고 파일 이 지워 지고 있을 때를 의미하며 이때 파 






기억해 야 한다(일정한 내용으로 ). 


EXT2_COMPR_FL_OxOO 04 

압축파일 파일 의 내 용이 압축된 다 . 파일 체 계코드는 이 파일 에 접 근할 때 반드 

시 압축/압축해 제알고리 듬을 리용해 야 한다 . 

EX T2_S YNCJf^_pX 0008 

동기갱신 이 파일디 스크표시 는 내 부중심파일디 스크표시 와 동기 를 유지해 야 한 

다 . 이 런 종류의 파일 상에 서 비 동기적 ！ / O 는 불가능하다 . 동기 갱 신은 
색 인마디 자체 나 간접블로크에만 적 용한다 . 자료블로크들은 항상 디 
스크에 비동기적으로 기록된다 . 

일부 색인마디들은 특별한 의미를 가지고 있다 . 


EXT2_BAD_INO 1 

파일체계의 불량블로크를 포함하는 파일 

EXT2_ROOT_INO 2 

파일체계의 뿌리등록부 

EXT2_ACL_IOX_INO 3 

ACL 색인마디 

EXT2_ACL_DATA_INO 4 

ACL 색인마디 

EXT2_BOT_LOADER_INO 5 

기동적재기를 포함하는 파일(아직 사용되지 
않음 ) 

EXT2_UNDEL_DIR_INO 6 

체계가 지워 지지 않는 파일 

EXT2_FIRST_INO 11 

특별한 의미를 가지지 않는 첫번째 색인마디 


등록 부 

등록부는 디 스크상의 파일 에 대 한 접 근경 로를 생 성하는데 리용되 는 특별 한 파일 이다 . 
색 인마디 가 많은 접 근경 로를 가지 고 있 다는것 을 리해하는것 은 아주 중요하다 . 등록부는 
파일 체 계 의 본질 적 인 부분이 기때 문에 특별 한 구조를 가지 고 있다 . 등록부파일 은 다음의 
형식을 가지는 입구점들의 목록이다 . 


start ext2_dir_entry{ 
unsigned long inode; 
unsigned short rec_len; 
unsigned short name_len; 

Char name[EXT2_NAME_LEN]; 

}； 

우의 구조체 의 성 분들에 대 하여 설 명하겠 다 . 


235 








inode 파일 의 색 인마디 에 대 하여 지 적 한다. 

rec_len 입 구점 레 코드의 길 이 

name_len 파일이름의 길이 

name 파일의 이름. 이 이름은 EXT 2_ NAME _ LEN 바이트의 최대길이를 가질수 

도 있다(판본 0.5 에서처 럼 255). 

등록부안의 매 개 파일 에 대 하여 등록부파일입 구점 이 존재한다. ext 2 fs 는 UNIX 파일 체 
계이 므로 등록부안의 첫 두개 입 구점 은 현 행등록부와 그것 의 상위등록부를 지 적하는 
“.” 과 파일 이다. 

배정알고리듬 

다음의 내 용은 ext 2 파일 체 계관리기 가 리용할 배 정알고리 듬이 다. 현재 많은 사용자들 
이 동일 한 콤퓨터상에 서 한개 이 상의 조작체 계 를 리용하고 있 다. 

만일 동일한 ext 2 구획 을 한개 이 상의 조작체 계 가 리용한다면 동일한 배 정알고리 듬을 
리용해 야 한다. 또한 다른 알고리 듬을 리용한다면 한 파일 체 계관리기 가 다른 파일 체 계관 
리기의 동작을 망치게 할수 있다. 

또한 다른 파일체계관리기 가 배정 에 피 해를 주지 않고 또 간략한 알고리듬을 리용한 
다면 고도로 효과 있는 배 정알고리 듬을 리용하는 관리기 를 가지 고 있 어 도 얼 마 쓸모가 
없다. 

아래 에 새 로운 색 인마디 를 배 정하는데 리 용되 는 규칙 들을 제 시한다. 

▼ 파일의 색인마디는 그것의 상위등록부의 같은 색인마디그룹에 배정된다. 

▲ 색인마디들은 그룹들속에 균등하게 배정된다. 

새 블로크를 배 정하는데 리 용되 는 규칙 들은 다음과 갈다. 

▼ 새 블로크는 색인마디처럼 갈은 그룹에 배정된다. 

▲ 련속적 인 블로크렬 을 배 정한다. 

물론 이러한 규칙대로 하는것이 불가능한 경우도 있을수 있다. 그러한 경우에 관리 
기는 블로크나 색 인마디중 어 디에 나 배정할수 있다. 

오유 처리 

이 부분에서는 표준 ext 2 파일체계가 오유를 어떻게 처리하는가 하느것을 서술한다. 
상위 블로크는 오유처 리 방법 을 관리하는 두가지 파라메터 를 가지 고 있 다. 

첫번째는 기 억의 상위블로크구조체 안의 s _ mount _ opt 성 원이 다. 이 값은 파일체계가 올 
려태 우기될 때 정의 되 는 선택항목으로부터 계산된다. 
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오유처리와 관련되는 값들은 다음과 같다. 


EXT2_M0UNT_ERR0RS_C0NT 오유가 생겨도 계속한다. 

EXT2_M0UNT_ERR0RS_R0 파일 체 계 를 읽 기 방식 으로 재 올려 태 우기 한다 . 

EXT 2 J«OUNT_ERRORS_PAN 1C 오유에 의 한 핵 심 부의 패 니 크 (위 기 ) 

두번째 파라메 터 는 디 스크의 상위 블로크구조체 의 s _ errors 성 원 이 다. 이 파라메 터 는 다 
음의 값들중에서 어느 하나를 취 한다. 


EXT2_ERR0RS_C0NTINUE 

오유가 발생한다고 해도 계속한다. 

EXT2_ERR0RS_R0 

파일 체 계 를 읽 기 전용방식 으로 재 올려 래 우기 한다 . 

EXT2_ERR0RS_PANIC 

핵심부의 단순한 패니크(위기) 

EXT2_ERR0RS_DEFAULT 

기정동작을 사용한다 (0.5 a 의 EXT 2_ ERRORS _ 
CONTINUE 와 같이). 


s _ mount _ opt 는 s _ errors 보다 우선권을 가진다. 
다음의 것 들은 선택 항목들의 목록이 다. 


bsddf 

minixdfmakes 
check=normal 


debug 

errors=contime 


errors=panic 
grpid,bsdgroups 
nogrpid,sysvgroup 


resgid=n 

sb=n 


grpquota,noquota f 


(*)'df ’가 bsd 처 럼 동작하게 한다. 

'df ’는 minix 처 럼 동작한다. 

(*) 파일 체 계 에 대 한 표준검 사 수행 

파일체 계에 대한 여유검사 수행 

개발자들에게만 허용 

(*) 파일 체 계오유를 계 수검 사 

오유가 발생하면 콤퓨터를 정지，패 니크 

객체들에 상위 에 관한 동일한 그롭과 id 를 부여 

(*) 새 객체들이 생성자의 그룹 id 를 가진다. 

예약블로크를 리용할수 있는 사용자 

예약블로크를 리용할수 있는 그룹 

이 위 치 에 서 다른 상위 블로크를 리 용 

배 정 량 선택 항목들 이 ext 2 에 의 하여 무시 된 다 . 


quota,usrquota 


원천쿄드 include/linux/ext2_fs.h 


linux/include/linux/ext2_fs.h 
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* Debug code 
#ifdef EXT2FS—DEBUG 

# define ext2_debug(f, a ...》 { \ 

printk ( ,f EXT2-fs DEBUG (%s, d) : %s: n , 

\ 一 FILE 一 , — LINE 一 , 一 FUNCTION_) ; \printk 
(f, ## a); \ 

} 

#else 

# define ext2_debug(f, a ...》 /**/ 

#endif 


* Special inodes numbers 
*/ 

#define EXT2_BAD_INO 1 
#define EXT2_R00T_IN0 2 
#define EXT2_ACL_IDX_IN0 3 
#define EXT2_ACL_DATA_IN0 4 
#define EXT2_B00T_L0ADER_IN0 5 
#define EXT2_UNDEL_DIR_IN0 6 


/* Bad blocks inode */ 

/* Root inode */ 

/* ACL inode */ 

/* ACL inode */ 

/* Boot loader inode */ 

/* Undelete directory inode */ 


/* First non-reserved inode for old ext2 filesystems */ 
#define EXT2_G00D_0LD_FIRST_IN0 11 


* The second extended file system magic number 
*/ 

#define EXT2_SUPER_MAGIC 0xEF53 

* Maximal count of links to a file 

#define EXT2_LINK_MAX 32000 

* Macro-instructions used to manage several block sizes 

#define EXT2_MIN_BLOCK_SIZE 1024 
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#define EXT2_MAX_BL0CK_SIZE 
#define EXT2_MIN_BL0CK_L0G_SIZE 
#ifdef 一 KERNEL 一 

# define EXT2_BL0CK_SIZE(s) 
#else 

# define EXT2_BL0CK_SIZE (s) 
#endif 

#define EXT2_ACLE_PER_BL0CK(s) 
#define EXT2_ADDR_PER_BL0CK(s) 


4096 

10 

( (s) - >s_blocksize) 

(EXT 2_MIN_BLOCK_S I ZE « (s) - 
>s_log_block_size) 

(EXT2_BLOCK_SIZE (s) / sizeof 
(struct ext2_acl_entry)) 
(EXT2_BLOCK_SIZE (s) / sizeof 
(_u32) ) 


#ifdef 一 KERNEL 一 

# define EXT2_BLOCK_SIZE_BITS(s) ((s)->s_blocksize_bits) 

#else 

# define EXT2_BLOCK_SIZE_BITS (s) ( (s) ->s_log_block_size + 10) 

#endif 


#ifdef 一 KERNEL 一 

#define EXT2_ADDR_PER_BLOCK_BITS(s) ( (s)->u.ext2_sb.s_addr__per_b1ock_bits) 

#define EXT2_INODE_SIZE (s) ((s)->u.ext2_sb.s_inode_size) 

#define EXT2_FIRST_INO(s) ( (s)->u.ext2_sb.s_first_ino) 

#else 

#define EXT2_INODE_SIZE (s) ( ( (s) ->s_rev_level == EXT2_GOOD_OLD_REV) ? 

EXT2_GOOD_OLD_INODE_S I ZE : \ 

(s) - >s_inode_size) 

#define EXT2_FIRST_INO (s) ( ( (s) - >s_rev_level == EXT2_GOOD_OLD_REV) ? 

EXT2_GOOD_OLD_FIRST_INO : \ 

(s) - >s_first_ino) 

#endif 


Macro-instructions used to manage fragments 


#define EXT2_MIN_FRAG_SIZE 
#define EXT2_MAX_FRAG_SIZE 
#define EXT2_MIN_FRAG_LOG_SIZE 
#ifdef 一 KERNEL 一 

# define EXT2_FRAG_SIZE(s) 

# define EXT2_FRAGS_PER_BLOCK(s) 


1024 

4096 

10 

((s) ->u.ext2_sb.s_frag_size) 

((s) 一 >u.ext2_sb.s_frags_per_block) 
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_ul6 bg_pad; 

_u32 bg_reserved [3] ; 


* Macro-instructions used to manage group descriptors 


#ifdef 一 KERNEL 一 

# define EXT2_BL0CKS_PER_GR0UP(s) 

# define EXT2_DESC_PER_BL0CK(s) 

# define EXT2_IN0DES_PER_GR0UP(s) 

# define EXT2_DESC_PER_BL0CK_BITS(s) 
#else 

# define EXT2_BL0CKS_PER_GR0UP(s) 

# define EXT2_DESC_PER_BL0CK(s) 

# define EXT2_IN0DES_PER_GR0UP(s) 
#endif 


((s)->u.ext2_sb.s_blocks_per_group) 
( (s) ->u.ext2_sb. s_desc_ ， per_block) 

( (s) 一〉 u. ext2_sb. s_inodes_per_group) 
((s) ->u.ext2_sb. s_desc_per_block_bits) 

( (s) - >s_blocks_per_group) 

(EXT2_BL0CK_SIZE (s) / sizeof 
(struct ext2_group_desc)) 

((s) 一〉 s_inodes_per_group) 


Constants relative to the data blocks 


#define EXT2_NDIR_BL0CKS 
#define EXT2_IND_BL0CK 

#define EXT2_DIND_BL0CK 

#define EXT2_TIND_BL0CK 

#define EXT2_N_BL0CKS 


12 

EXT2_NDIR_BL0CKS 
(EXT2_IND_BL0CK + 1) 
(EXT2_DIND_BL0CK + 1) 
(EXT2_TIND_BL0CK + 1) 


* Inode flags 

#define EXT2_SECRM_FL 

#define EXT2_UNRM_FL 

#define EXT2_C0MPR_FL 

#define EXT2_SYNC_FL 
#define EXT2_IMMUTABLE_FL 
#define EXT2_APPEND_FL 
append */ 

#define EXT2_N0DUMP_FL 
#define EXT2_N0ATIME_FL 
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0x00000001 

0x00000002 

0x00000004 

0x00000008 

0x00000010 

0x00000020 


/* Secure deletion */ 

/* Undelete */ 

/* Compress file */ 

/* Synchronous updates */ 
/* Immutable file */ 

/* writes to file may only 


0x00000040 /* do not dump file */ 
0x00000080 /* do not update atime */ 































#if defined (_KERNEL_) | | defined (_linux_) 

#define i_reservedl osdl.linuxl.l_i_reservedl 

#define i_frag osd2.Iinux2.l_i_frag 

#define i_fsize osd2.Iinux2.l_i_fsize 

#define i_uid_lowi_uid 
#define i_gid_lowi_gid 

#define i_uid_high osd2.Iinux2.l_i_uid_high 

#define i_gid_high osd2.Iinux2.l_i_gid_high 

#define i_reserved2 osd2.Iinux2.I_i_reserved2 

#endif 


#ifdef 一 hurd 一 

#define i_translator 
#define i_frag 
#define i_fsize 
#define i_uid_high 
#define i_gid_high 
#define i_author osd2.hurd2.h_i_author 
#endif 


osdl.hurdl 
osd2.hurd2 
osd2.hurd2 
osd2.hurd2 
osd2.hurd2 


h_i_u i d_h i gh 
h_i_g i d_h i gh 


#ifdef _masix_ 

#define i_reservedl 
#define i_frag 
#define i_fsize 
#define i_reserved2 
#endif 
/* 


osdl.masixl.m_i_reservedl 
osd2.masix2.m_i_frag 
osd2.masix2.m_i_f size 
osd2.masix2.m_i_reserved2 


* File system states 

#define EXT2_VALID_FS 0x0001/* Unmounted cleanly */ 

#define EXT2_ERROR_FS 0x0002/* Errors detected */ 


Mount flags 

/* Do mount-time checks */ 
/* Create files with 
directory’s group */ 
#define EXT2—MOUNT—DEBUG 0x0008/* Some debugging messages */ 

#define EXT2_MOUNT_ERRORS_CONT 0x0010 /* Continue on errors */ 
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#define EXT2_MOUNT_CHECK 0x0001 

#define EXT2_MOUNT_GRPID 0x0004 



























#define EXT2_M0UNT_ERR0RS_R0 
*/ 

#define EXT2_M0UNT_ERR0RS_PANIC 
#define EXT2_M0UNT_MINIX_DF 
#define EXT2_MOUNT_NO_UID32 


0x0020 /* Remount fs ro on errors 

0x0040 /* Panic on errors */ 


0x0080/* Mimics the Minix statfs */ 


0x0200 /* Disable 32-bit UIDs */ 


#define clear_opt (o, opt) 
#define set_opt (o, opt) 
#define test_opt(sb, opt) 


/* 


o &= ~EXT2_MOUNT_##opt 
o |= EXT 2_MOUNT_# # opt 
((sb)->u.ext2_sb.s_mount_opt & \ 
EXT 2_MOUNT_# #opt) 


' Maximal mount counts between two filesystem checks 


#define EXT2_DFL_MAX_MNT_COUNT 
#define EXT2_DFL_CHECKINTERVAL 


/* Allow 20 mounts */ 

/* Don 1 1 use interval check */ 


#define EXT2_ERRORS_CONTINUE 
#define EXT2_ERRORS_RO 
#define EXT2_ERRORS_PANIC 
#define EXT2_ERRORS_DEFAULT 


1 /* Continue execution */ 

2 /* Remount fs read-only */ 

3 /* Panic " 

EXT2_ERRORS_CONTINUE 


* Structure of the super block 

struct ext2_super_block { 

_u32 s_inodes_count; 

_u32 s_blocks_count; 

_u32 s_r_blocks_count; 

_u32 s_free_blocks_count; 

_u32 s_free_inodes_count; 

_u32 s_first_data_block; 

_u32 s_log_block_size; 

_s32 s_log_frag_size; /* 

_u32 s_blocks_per_group; 

_u32 s_frags_per_group; 

_u32 s_inodes_per_group; 

_u32 s_mtime; 


/* Inodes count */ 

/* Blocks count */ 

/* Reserved blocks count */ 
/* Free blocks count */ 

/* Free inodes count */ 

/* First Data Block */ 

/* Block size */ 

Fragment size */ 

/* # Blocks per group */ 

/* # Fragments per group */ 
/* # Inodes per group */ 

/* Mount time */ 
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_u32 s_wtime; 

_ul6 s_mnt_count; 

_si6 s_max_mnt_count; 

_ul6 s_magic; 

_ul6 s_state; 

_ul6 s_errors; 

_ul6 s_minor_rev_leve 1; 

_u32 s_lastcheck; 

_u32 s_checkinterval; 

_u32 s_creator_os; 

_u32 s_rev_level; 

_ul6 s_def_resuid; 

_ul6 s_def_resgid; 


/* Write time */ 

/* Mount count */ 

/* Maximal mount count */ 

/* Magic signature */ 

/* File system state */ 

/* Behaviour when detecting errors */ 
/* minor revision level */ 

/* time of last check */ 

/* max. time between checks */ 

/* OS */ 

/* Revision level */ 

/* Default uid for reserved blocks */ 
/* Default gid for reserved blocks */ 


These fields are for EXT2 一 DYNAMIC 一 REV superblocks only. 


Note : the difference between the compatible feature set and 
the incompatible feature set is that if there is a bit set 
in the incompatible feature set that the kernel doesn’t 
know about, it should refuse to mount the filesystem. 


e2fsck 1 s requirements are more strict; if it doesn’t know 
about a feature in either the compatible or incompatible 
feature set, it must abort and not try to meddle with 
things it doesn 1 t understand... 


_u32 s_first_ino; /* First non-reserved inode */ 

_ul6 s_inode_size; /★ size of inode structure */ 


— ul6 
一 u32 
一 u32 
一 u32 
_u8 


s_block_group_nr; /* 
s_feature_compat; 
s_feature_incompat; 
s_feature_ro_compat; 



block group # of this superblock */ 

/★ compatible feature set */ 

/★ incompatible feature set */ 

/* readonly-compatible feature set */ 
/* 128-bit uuid for volume */ 


char s_volume_name [16]; /* volume name */ 

char s_last_mounted[64] ; /* directory where last mounted */ 

_u32 s_algorithm_usage_bitmap; /* For compression */ 


/* 


' Performance hints. Directory preallocation should only 
■ happen if the EXT2_C0MPAT_PREALL0C flag is on. 
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— u8 s_prealloc_blocks; /* Nr of blocks to try to preallocate*/ 

_u8 s_prealloc_dir_blocks; /* Nr to preallocate for dirs */ 

_ul6 s_paddingl; 

— u32 s_reserved[204] ; /* Padding to the end of the block */ 


#ifdef 一 KERNEL 一 

#define EXT2_SB(sb) (& ((sb)->u.ext2_sb)) 

#else 

/* Assume that user mode programs are passing in an ext2fs superblock, 
not 

* a kernel struct super_block. This will allow us to call the feature-test 

* macros from user land. */ 

#define EXT2_SB(sb) (sb) 

#endif 


* Codes for operating systems 

#define EXT2_0S_Linux 0 
#define EXT2_0S_HURD 1 
#define EXT2_0S_MASIX 2 
#define EXT2_0S_FREEBSD 3 
#define EXT2_0S_LITES 4 


* Revision levels 

#define EXT2_G00D_0LD_REV 
#define EXT2_DYNAMIC_REV 


/* The good old (original) format */ 
/* V2 format w/ dynamic inode sizes */ 


#define EXT2_CURRENT_REV EXT2_G00D_0LD_REV 

#define EXT2_MAX_SUPP_REV EXT2_DYNAMIC_REV 


#define EXT2_G00D_0LD_IN0DE_SIZE 128 


* Feature set definitions 
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( EXT2_SB (sb) - >s_es->s_feature_compat & cpu_to_le32 (mask) ) 
#define EXT2_HAS_R0_C0MPAT_FEATURE(sb f mask) \ 

( EXT2_SB(sb) - >s_es->s_feature_ro_compat & cpu_to_le32(mask) ) 
#define EXT2_HAS_INC0MPAT_FEATURE(sb,mask) \ 

( EXT2_SB(sb) - >s_es->s_feature_incompat & cpu_to_le32(mask) ) 
#define EXT2_SET_C0MPAT_FEATURE(sb,mask) \ 

EXT2_SB (sb) - >s_es - >s_feature_compat | = cpu_to_le32 (mask) 
#define EXT2_SET_R0_C0MPAT_FEATURE(sb,mask) \ 

EXT2_SB (sb) - >s_es->s_feature_ro_compat | = cpu_to_le32 (mask) 
#define EXT2_SET_INC0MPAT_FEATURE(sb,mask) \ 

EXT2_SB(sb) - >s_es->s_feature_incompat | = cpu_to_le32(mask) 
#define EXT2_CLEAR_C0MPAT_FEATURE(sb f mask) \ 

EXT2_SB(sb) - >s_es->s_feature_compat &= -cpu_to_le32(mask) 
#define EXT2_CLEAR_R0_C0MPAT_FEATURE(sb,mask) \ 

EXT2_SB (sb) - >s_es->s_feature_ro_compat &= -cpu_to_le32 (mask) 
#define EXT2_CLEAR_INC0MPAT_FEATURE(sb f mask) \ 

EXT2_SB(sb) - >s_es->s_feature_incompat &= -cpu_to_le32(mask) 


#define EXT2_FEATURE_C0MPAT_DIR_PREALL0C 0x0001 

#define EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER 0x0001 

#define EXT2_FEATURE_RO_COMPAT_LARGE_FILE 0x0002 

#define EXT2_FEATURE_RO_COMPAT_BTREE_DIR 0x0004 

#define EXT2_FEATURE_INCOMPAT_COMPRESSION 0x0001 

#define EXT2_FEATURE_INCOMPAT_FILETYPE 0x0002 

#define EXT2_FEATURE_COMPAT_SUPP 0 

#define EXT2_FEATURE_INCOMPAT_SUPP EXT2_FEATURE_INCOMPAT_FILETYPE 
#define EXT2_FEATURE_RO_COMPAT_SUPP (EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER | 
EXT2_FEATURE_RO_COMPAT_LARGE_FILE | 
EXT2_FEATURE_RO_COMPAT_BTREE_DIR) 


* Default values for user and/or group using reserved blocks 

#define EXT2_DEF_RESUID 0 

#define EXT2_DEF_RESGID 0 
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#define EXT2_FT_MAX 8 

* EXT2_DIR_PAD defines the directory entries boundaries 

* NOTE : It must be a multiple of 4 

#define EXT2_DIR_PAD 4 

#define EXT2_DIR_R0UND (EXT2_DIR_PAD - 1) 

#define EXT2_DIR_REC_LEN (name_len) ( (name_len) + 8 + EXT2_DIR_R0UND) & \ 
-EXT2_DIR_R0UND) 

#ifdef 一 KERNEL 一 

* Function prototypes 


* Ok, these declarations are also in <linux/kernel. h> but none of the 

* ext2 source programs needs to include it so they are duplicated here. 
*/ 

# define NORET_TYPE /**/ 

# define ATTRIB_NORET 一 attribute 一 ( (noreturn)) 

# define NORET—AND noreturn. 


/* acl.c */ 

extern int ext2_permission (struct inode int) ; 


/* balloc.c */ 

extern int ext2_bg_has_super(struct super_block *sb f int group); 
extern unsigned long ext2_bg_num_gdb(struct super—block *sb, int group); 
extern int ext2_new_block (struct inode *, unsigned long, 

— u32 *, 一 u32 int *); 

extern void ext2_free_blocks (struct inode *, unsigned long, 
unsigned long); 

extern unsigned long ext2_count_free 一 blocks (struct super_block *) ; 
extern void ext2_check_blocks_bitmap (struct super_block *) ; 
extern struct ext2_group_desc * ext2_get_group_desc(struct super_block 
* sb, unsigned int block—group, struct 
buffer_head ** bh) ; 
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extern struct inode—operations ext2_dir_inode_operations; 


/* super.c */ 

extern void ext2_error (struct super—block *, const char *, const char . ..) 

一 attribute 一 ((format (printf, 3, 4) ) ) ; 
extern NORET—TYPE void ext2_panic (struct super_block const char *, 
const char * r . . .) 

— attribute 一 ((NORET_AND format (printf, 3, 4) ) ) ; 
extern void ext2_warning (struct super_block const char *, const 
char *, . . .) 

— attribute — ((format (printf, 3, 4) )) ; 
extern void ext2_update_dynamic_rev (struct super—block *sb) ; 
extern void ext2_put_super (struct super_block *); 
extern void ext2_write_super (struct super_block *); 
extern int ext2_remount (struct super—block *, int *, char *) ; 
extern struct super—block * ext2_read_super (struct super—block *,void *,int); 
extern int ext2_statfs (struct super_block struct statfs *); 

/* truncate.c */ 

extern void ext2_truncate (struct inode *) ; 


/* 


' Inodes and files < 


/* dir.c */ 

extern struct file_operations ext2_dir_operations; 

/* file.c */ 

extern struct inode—operations ext2_file_inode_operations; 
extern struct file 一 operations ext2_file_operations; 


/* symlink.c */ 

extern struct inode—operations ext2_fast_symlink_inode_operations; 
extern struct address_space_operations ext2_aops; 

#endif /* 一 KERNEL 一 */ 

#endif /* _Linux_EXT2_FS_H */ 

253 






제 8 장. Linux 용실행기록파일체계 

실행기 록 혹은 등록파일체 계 들은 ex 任 fs 파일체 계 와 같은 보다 단순한 파일체 계 들의 
일관성 문제 를 제거하였으나 속도상에서의 문제 를 산생 시 키 였다. 

이제 고찰하겠지 만 이 체 계 들은 자료기지관리체 계 에서처 럼 파일체 계안에서 갱 신되는 
거래라는 개념을 도입하여 파일을 갱신하기전에 갱신사건을 기억하기 위하여 가동일지를 
사용한다. 일단 갱신되면 가동일지내용입구점은 실행된것으로 표기되며 이러한 보충적인 
조작으로 하여 파일체계전체에 대하여서는 성능이 떨어 지게 된다. 일부 실행기록 一 사용 
등록파일체계들은 다른 체계들보다 더 빠르다. 

이 장에서 우리 는 JFS (실 행기 록파일체 계)의 실현에 대 하여 고찰한다. JFS 는 상위블로 
크와 Linux 가상파일 체 계 에 의 하여 요청 되 는 파일 체 계 호출을 제 공한다. 가동일 지 에 기 초 
한 바이 트준위파일체 계 인 JFS 는 견고하고 유연한 특성 을 다 가지 고 있 다. 

주로 높은 생산성과 거래지향의 실현요구，고성능봉사기를 목적으로 만들어 졌다는데로 
부터 역시 JFS 는 성능과 실현성을 다같이 요구하는 클라이 언트형식 에 리용할수 있다. 

IBM 의 실행 기 록파일체 계 인 JFS 는 2000년 2월에 공개되 여 리 용할수 있게 되 였 다. 

JFS 의 기본자료구조와 알고리듬 

JFS 에 대한 구체적인 연구결과는 실현상 본보기로 될만한 좋은 점들을 가지고 있다. 
자료구조가 명백하며 가장 단순한 형태로 축소되여 있다. 변수이름공간이 지능적으로 리 
용되 며 함수들도 쓸모 있 게 기 교화되 여 있 다. 이 구조와 알고리 듬을 해 석하여 보겠 다. 

상위블로크 : 1 차집합상우 I 블로크와 2차집합상우 I 블로크 

상위블로크는 집합의 크기，배정그룹의 크기，집합블로크의 크기 등과 같은 집합범위 
정보를 포함한다. 

2차집 합상위블로크는 1차집 합상위블로크의 직 접 복사판이 며 1차집 합상위블로크가 파 
손된 경 우에 리 용된 다. 

이 상위블로크들은 JFS 가 어 떤 다른 정 보에 의 존함이 없 이 항상 찾을수 있도록 고정 
된 위치에 존재한다. 

상위 블로크구조체 는 linux\include\linux\JFS\JFS_superblock.h 의 struct JFS_ super block 
에서 정의된다. 

색인마디 

JFS 디스크상의 색 인마디는 512byte 이며 4개의 기 본정 보모임 을 포함한다. 

▼ 첫번째 모임 은 JFS 객체의 POSIX 속성 을 서 술한다. 
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• 두번째 모임은 JFS 객체의 보충적 인 속성 을 서 술한다. 이 속성들은 VFS 지 원에 필요 
한 정 보와 OS 환경 에 대 한 특정정 보 그리 고 B + 나무용머 리부정 보들을 포함한다. 

• 세번째 모임 은 B + 나무의 뿌리의 범위배 정서 술자를 포함하든지 혹은 직 결자료를 
포함하게 된다. 

▲ 네번째 모임 은 확장된 속성 들，더 많은 직 결자료 혹은 보충적 인 범위배정서술자 
들을 포함한다. 

디스크상의 색인마디구조체정의는 linux \ include \ JFS \ JFS _ dinode . h 에서 struct dinode 로 
정의된다. 

표준관리용편의프로그람 

피크는 파일체계를 생성 하고 관리하는데 필요한 표준적 인 관리편의프로그람들을 제 
공한다. 

1. 파일체 계 를 생성한다. 이 편의프로그람은 정의 된 구동기상에 JFS 파일체 계를 초기 
화할 때 mkfs 명 령 의 JFS 정 의부분을 제 공한다. 편의프로그람은 낮은 준위 에 서 동 
작하며 파일체 계 가 존재하게 될 기 록권의 임 의의 생성 一초기 화가 보다 높은 준 
위 의 편의프로그람외 부에 서 조종된 다고 가정한다. 사용자는 파일체 계 의 특성 을 
변경시 킬수 있는 mkfs 를 실 행하여 블로크크기 와 갈은 정 보들을 제 공할수 있 다. 

2. 파일체 계 를 검 사회 복한다. 이 편의프로그람은 fsck 명 령 의 JFS 정 의 부분을 제 공한다. 
또한 파일체 계의 일관성을 검 열하고 손상된 부분을 회복하며 가동일지를 재생하 
고 파일 체 계메 타자료에 대 한 변경 내 용을 통지한다. 파일 체 계 가 가동일지 재 생 의 
결과 깨끗하다는것 이 알려 지면 다음의 동작은 더 진행되지 않는다. 파일체계가 
깨 끗해 진것 같지 않으면 어 떤 원인에 의하여 가동일지 가 완전히 그리 고 정 확히 
재 생 되지 않았다는것 을 지 적하여 파일체 계 가 완전히 회 복되 게 한다. 완전하고도 
집중적 인 검사를 수행하는데서 검사 一 회복편의프로그람의 1차적목적은 파일체계 
파손이나 고장을 막을수 있는 현실성 있는 파일체계상태를 얻는데 있다. 2차적목 
적 은 손상에 직 면하여 자료를 보존하는것 이 다. 이것은 편의프로그람이 파일체 계 
일 관성을 보장하는 견지 에 서 자료를 대 피시 킨다는것을 의 미 한다. 편의프로그람이 
구조적으로 불일치된 파일이나 등록부를 어떠한 가정도 없이 일치한 상태로 회 
복하는데 필요한 정보들을 가지고 있지 못할 때 자료는 손상된다. 일관성이 보장 
되지 않은 파일이나 등록부가 있는 경우에 전체 파일이나 등록부는 어느 한 부 
분도 보존하지 못하고 손상되 고 만다. 손상된 등록부의 지 우기 에 의하여 홀로 남 
게 된 임의의 파일이나 등록부들은 파일체계의 뿌리에 위치하고 있는 lost+found 
등록부에 배치된다. 파일체계검사 一 회복편의 프로그람에 대하여 중요하게 고려 해 
야 할 문제는 그것 이 요구하는 가상기 억의 크기 이 다. 대표적으로 이 편의프로그 
탐에 요구되 는 기 억은 요구한 가상기 억 용량이 파일체계안의 개 별적블로크들의 
배정 상태 를 추적하는데 리용되 기때 문에 파일체 계의 크기 에 의존하게 된다. 파일 


255 



체계가 더 커지면 블로크수도 증가하며 따라서 이 블로크들을 추적 하는데 요구 
되는 가상기 억의 용량도 커지게 된다. JFS 검사一회 복편의프로그람의 설계는 파일 
체 계의 블로크수보다도 오히 려 파일체 계안의 파일 이 나 등록부수에 의하여 가상 
기억요구가 제기되던 초기의 Linux fsck 와는 다르다. JFS 검사 一 회복편의프로그람 
의 가상기 억요구는 파일과 등록부당 32 byte 의 차수로 되든가 혹은 파일체계크기 
에는 무관계하게 백만개의 파일이 나 등록부들을 포함하는 체계 에 대하여 약 
32 MB 에 해 당된 다. 다른 모든 파일 체 계 와 마찬가지 로 JFS 편의프로그람은 실제 적 
인 파일체 계 에 배 치된 작은 규모의 예 약된 작업구역 을 리용하여 블로크배정상태 
를 축적할것을 요구하지만 거기에 가상기억을 리용하는 방법은 피한다. 

기동시 JFS 의 설정 

기동시 에 파일체 계생성편의프로그람 즉 mkfs 는 올려태 우기되 는 매 개 론리기 록권(구 
획)안에 총체 적 으로 포함되 는 한개 의 집 합을 생 성한다. 이 집 합은 특정한 양식 에 따라 
배정된 디스크블로크들의 배렬이다. 

이 배렬을 다음과 같은 내용을 포함한다. 

▼ JFS 집 합으로서 의 구획 을 식 별 하는 상위블로크 

▲ 집 합안의 매 자료블로크의 배정상태를 표시하는 배정표 

■로크배정표 

블로크배정표는 전체 집 합에 관하여 배정되 였거 나 비 여 있는 블로크들을 추적하는데 
리용된다. 집 합안의 모든 파일모임은 동일한 디스크블로크의 풀을 공유하기때문에 이 배 
정 표는 디 스크블로크들을 배정하거 나 배정해제할 때 집 합내 의 모든 파일모임 *들에 의하 
여 리용된다. 

모든 준위 가 요구되 지 않으면 블로크표 (block map ) 색 인마디 는 매 개 사용되지 않은 
준위의 첫번째 폐지에 구멍이 있는 성긴 파일로 될것이다. 

JFS 는 현실적 으로 조종자료가 갱 신된다는것 을 확인하기 위하여 위 임하는 방략을 리 
용한다.《실현가능한 갱신》이라는것은 체계고장에 직면하여 일관성 있는 JFS 구조체와 
자원배 정상태 가 유지 된 다는것 을 의미 한다. 


파일모임은 ext2fs 파일체계와 같이 올려태우기가능한 실체들이다. 파일모임은 파일과 등록 
부들을 관리한다. 파일과 등록부들은 색 인마디 에 의하여 일관성 있게 표시된다. 매 색 인마 
디들은 파일 이 나 등록부의 속성 을 표현 하며 디 스크상의 파일 이 나 등록부의 자료들을 찾는 
데 서 출발점 으로 보존한다. JFS 도 역 시 파일모임안의 매 개 색 인마디 의 디 스크상에 서 위 치 
와 배정상태를 표현하는 표와 같은 그러한 다른 파일체계객체를 표현하는데 색인마디를 리 
용한다. 
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블로크배 정표가 일 관성 있는 상태 에 있 다는것 을 확인하기 위하여 JFS 는 dmap 구조 
체 에 두개 의 표를 보존하는데 하나는 작업표이고 다른 하나는 영 구표이 다. 작업표는 
현행배 정상태 를 기 록한다. 영 구표는 디 스크상에 서 보았거 나 JFS 의 가동일지 안에 있는 
레코드에 의하여 표시되였거나 혹은 JFS 거래에 위임된 배정상태를 기록한다. 

집합블로크가 개방될 때에는 영구표가 먼저 갱신되며 배정될 때에는 작업표가 먼저 
갱 신된다. 일부 0( 령)은 빈 자원을 표시하며 1은 배정된 원천을 표시한다. 

블로크배 정표의 dmap 조종폐 지 들은 잎 준위 가 1024개 의 요소를 포함한것 을 제 외 하고 
는 dmap 구조체의 나무와 류사한 나무를《포함한다》. 

dmap 조종폐 지 는 struct dmapctl _ t 에 의 하여 정의 되 며 이 구조체 는 linux \ include\linux 
JFS \ JFS _ dmap . h 에서 찾아 볼수 있 다. 

블로크배 정 표의 꼭대 기 에 는 표조종구조체 인 struct dbmap _ t 가 있 다. 이 구조체 에 는 배 
정그룹의 람색시 간을 고속화하는 요약정 보가 포함되 여 있 는데 이 때 배 정그룹읔 ( AG ) 평 
균적 인 빈 공간보다 더 많은 공간을 가지게 된다. 

구조체 는 Unux \ include \ linux \ JFS \ JFS _ dmap . h 에 서 찾을수 있 다. 

블로크배정표는 정기적으로 기록되지 않는다. 이 표는 가동일지의 재등록에 의한 회 
복시간에 복구될 수 있 거 나 혹은 fsck 에 의하여 재구성 될 수 있 다. 

색인마디배정표 

색 인마디 배 정표는 앞방향검 색문제 를 해 결 한다. 

집합과 매개 파일모임은 색 인마디배정표를 보존하는데 이 표는 색 인마디배정그룹 
( IAG ) 의 동적 배 렬이 다. 이 IAG 는 색 인마디 배 정표에 필요한 자료이 다. 집 합에 관하여 서 는 
색 인마디 배 정표에 따라 넘 기 기 된 색 인마디 는 집 합색 인마디표로 된 다. 파일 모임 에 관하여 
서 는 색 인마디 배 정 표에 의 하여 넘 기 기 되 는 색 인마디 가 파일 색 인마디 표로 된 다. 

매 IAG 는 4 KB 의 크기를 가지며 디 스크상에서 128개의 물리 적색 인마디범 위를 표시 
한다. 매 색 인마디내 용은 32개 의 색 인마디 를 포함하고 있기때 문에 매 개 IAG 는 4096개 의 
색 인마디 를 표시 하게 된 다. 

IAG 는 집합안의 어디에나 존재할수 있다. IAG 에 대한 전체 색인마디의 내용은 한개 
의 배정그룹에 존재한다. IAG 는 모든 범위의 색 인마디 가 개 방될 때까지 해 당 AG 에 속박 
된다. 그 시 점 에서 색 인마디크기 는 임의 의 AG 안에 배정 될수 있으며 IAG 는 그 AG 에 련 
결된다. IAG 는 linux \ include \ linux \ JFS \ JFS _ imap . h 파일의 iag _ t 구조체 에 의 하여 정의된다. 

색인마디배정표의 첫 4 K 페지는 조종폐지이며 이 페지는 색인마디배정표에 관한 요 
약정보들을 포함한다. 

dinomap _ t 구조체에 대한 정의는 linux \ indude \ linux \ JFS \ JFSmap . h 파일에서 찾아 볼수 있다. 

추상적 으로는 색 인마디 배 정표가 동기적 으로 확장가능한 IAG 구조체 배 렬 즉 struct iag 
inode _ map [ l .. N ] 이 며 물리 적 으로는 집 합내 에 존재 하는 파일 그자체 이 다. 집 합색 인마디 배 
정 표는 집 합자체마디 에 의하여 서 술된 다. 

파일 모임 색 인마디 배 정 표는 filesetjnode 에 의 하여 표현된다. 이 표의 폐지 는 표준 B + 
나무첨수화에 의거하여 필요에 따라 배정되기도 하고 개 방되기도 한다. 

B + 나무의 열쇠 는 IAG 페 지 의 바이 트변위값이 다. 
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AG 자유색인마디목록 


AG 자유색 인마디목록은 거끌검 색문제 를 해 결할수 있게 한다. 집 합을 확장하거 나 줄 
이 는데 서 의 휴지 시 간을 줄이 기 위하여 JFS 는 매 집 합당 허 용되 는 최 대 배 정그를들의 수를 
설정할수 있 다. 따라서 AG 자유색 인마디 목록의 머 리 부수는 고정 될수도 있 다. 목록에 관한 
머 리부는 색 인마디배 정표의 조종폐 지 안에 존재한다. n 번째 입 구점 은 n 번째 AG 에 포함되 
는 자유색 인마디 를 가진 모든 색 인마디 배 정표입 구점 들의 2중련결목록에 대 한 머 리 부이다. 

IAG 번호는 목록안에서 첨수로 리용된다. A -1 은 목록의 끝을 지적한다. 매개 IAG 조종 
부분은 목록에 대 한 앞방향 혹은 뒤방향 지 적자를 포함한다. AG 자유색 인마디 목록을 표시 
하는 정의는 linux \ include \ linux \ JFS \ JFS _ imap . h 파일의 dinomap _ t 구조체에 있다. 

IAG 자유목록 

IAG 자유목록은 자유색 인마디번호를 탐색하는데 리용한다. 이 목록은 JFS 가 임의 의 
대 응하는 배정색 인마디크기 가 없이 도 IAG 을 찾을수 있게 한다. IAG 자유목록을 표현하는 
정의는 Unux \ includeUinux \ JFS \ JFS _ dinode . h 파일의 inomap _ t 구조체에 있다. 

과일모임배정표색인마디 

집 합색 인마디표안의 파일모임배 정표색 인마디들은 특별한 형 식의 색 인마디 이 다. 이 것 
들은 파일모임 을 표현하기 때 문에 파일모임 에 관하여서 는《상위-색 인마디》로 된다. 표준 
색 인마디자료대 신에 파일모임배정색 인마디는 색 인마디의 웃절반에 몇 가지 파일모임정의 
용정보들을 포함한다. 이 색 인마디표들은 또한 B + 나무의 파일모임배정표의 위 치를 추적하 
는데 리용된 다. 이 구조체는 lMux \ include \ linux \ JFS \ JFS _ dinode . h 파일의 struct dinode _ t 구조체 
에 의하여 정의된다. 

매 JFS 객 체 는 색 인마디 에 의하여 표현된 다. 색 인마디 는 시 간표식 이 나 파일 형 식 (정 규 
적 인 VS . 등록부)과 같은 객체-정의형정 보를 포함한다. 이 정 보들은 역 시 배 정크기 를 기 
록하기 위한 B + 나무를《 포함한다》. 

특별 히 모든 JFS 메 타자료구조체(상위블로크는 제 외 )가《 파일》로 표현된 다는데 대 
하여 강조한다. 이 자료들에 대 한 색 인마디구조체 를 리용하여 자료의 양식 은(디 스크구역 
에서)계층적으로 확장가능하게 된다. 

등록부는 사용자정의된 이름들을 파일이나 등록부들에 배정된 색인마디들로 넘기며 
전형 적 인 이 름계 층을 형 성한다. 

파일은 사용자자료를 포함하며 자료에 는 아무러 한 제 한이 나 양식 들이 내재되 여 
있지 않다. 따라서 사용자자료는 JFS 에 의하여 해석되지 않는 자료의 흐름으로서 취 
급된 다. 

색인마디에 뿌리로 되여 있는 범위에 기초한 구조체는 디스크블로크들로 파일자료 
들을 넘기기하는데 리용된다.《파일》은 범위순차로 배정된다. 

또한 집 합의 상위블 로크， 디 스크 배 정 표， 파일 서 술자색 인마디 표， 색 인마디，등록부，주 
소화구조체들은 JFS 조종구조체 실례로 메타자료들을 이루고 있다. 
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다른 과일체계로부터 JFS 를 분류하기 우 I 한 설계상 특성 

JFS 는 현존 파일체계에 보충하는 방법으로가 아니라 시작으로부터 완전히 집중화된 
실행기록수법을 가질수 있게 설계되여 있다. 게다가 JFS 의 수많은 서로 다른 특성들은 
피크를 다른 파일체계들과 구별할수 있게 한다. 

• 내부적 JFS 의 한계 

JFS 는 완전 한 64bit 파일 체 계 이 다. 모든 고유한 파일 체 계구조체마당들이 64bit 로 
되여 있다. 이것은 JFS 가 대규모파일이나 구획을 지원할수 있게 해춘다. 

• 제거가능한 매체 

JFS 는 파일 체 계기 초장치 로서 플로피 디 스크를 지 원 하지 못한다. 

• 파일체계의 크기 

피크에 의하여 지 원되 는 최 대파일 체 계 의 크기 는 16MB 이 다. 파일 체 계 의 최 대 크기 
는 파일 체 계메 타자료구조체 에 의하여 지 원되 는 블로크의 최 대 수와 파일 체 계블로 
크크기 의 함수이다. 

JFS 는 512TB 로부터(블로크크기 512B) 4PB (블로크크기 4KB) 까지의 최대파일체계 
를 지원할수 있다. 

• 파일크기 

최 대 파일 크기 는 VFS 체 계 가 지 원하는 최 대 파일 크기 이 다. 실 례 로 VFS 체 계 가 32bit 
만 지원하면 이것이 파일의 크기로 된다. 

• 주소화구조 

JFS 는 철저하게 범위 에 기초한 주소화구조로서 B+ 나무를 리용한다. JFS 가 B+ 나 
무를 지 원하는 일부 구역은 범위 에 따르는 배정방법 에 기초하고 있다. 

파일 은 B+ 나무의 뿌리 를 포함하는 색 인마디 에 의하여 표현되 는데 이 때 B+ 나무의 뿌 
리는 사용자자료를 포함하는 범위를 서술한다. 범위는 JFS 객체를 한 단위로 하여 배정된 
련속집합블로크들의 렬이 다. 매개의 범위는 단일한 집 합내 에 완전히 포함된다. 

범위를 정의하는데는 두개의 값 즉 길이와 주소가 요구된다. 길이는 집합의 블로크 
크기를 단위 로 하여 계산된다. JFS 는 범위를 표시하는 24bit 값을 사용한다. 그리하여 하 
나의 범위는 1부터 (2 24 _1)의 집합블로크단위로 배렬될수 있다. 주소는 집합블로크들의 
단위(집합의 시작으로부터 블로크의 변위)로 된 범위의 첫번째 블로크의 주소이다. 범위 
는 다중배정그롭들로 늘쿨수 있다. 이 범위들은 새 로운 범위를 삽입하거 나 특정한 범위 
를 찾아 내 는 등의 성 능최 량화를 위 하여 B+ 나무로 첨 수화된다. 512byte 의 집 합블로크범 
위(허 용가능한 최소값)는 최대로 512*(2 M -1) 까지 정의할수 있다 (8GB 보다 적게). 4096바이트 
의 집 합블로크범 위 (허 용가능한 최 대 값)로써 는 최 대 크기 를 4096*(2 24 -l)byte 까지 정 의 할수 
있다 (64GB 보다 적게). 이 한계는 단일범위 의 경 우에 만 적 용한다. 이 것들은 파일체 계전반 
에 걸쳐 그 어떤 영향도 주지 않는다. 

사용자정의집합블로크와 결합된 범위에 기초한 파일체계는 JFS 로 하여금 내부의 토 
막화를 따로따로 지원할수 없게 한다. 사용자는 작은 범위로 된 많은 파일들로 집합의 
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내 부토막화를 최 소화하기 위하여 작은 규모의 집 합블로크범 위 (실 례 로 512byte) 토서 집 합 
을 배 치할수 있 다. 

일 반적 으로 JFS 의 배 정 방법 은 최 소린 접 배 정 방법 으로 진 행 하여 즉 가능한 정 도의 크 
기로 린접되도록 배정함으로써 련속적인 배정이 최대화되도록 한다. 이 방법은 대규모의 
I/O 전송에 서도 성 능을 개 선한다. 

이 름에 의하여 정 렬된 B + 나무는 특정한 등록부의 입 구점 을 지 적하는 능력 을 높이 는 
데 리용한다. 

피크는 적 극적 인 블로크배 정조작에 따라 파일안의 론리 적변위값들을 디 스크상의 물리 
적주소로 넘 기 는데 서 집 약적 이고도 효과적 이 고 유연한 구조체 로 된 다. 이 미 언급된바와 
같이 범위는 한개 단위 로 파일안에 배정된 련속적 인 블로크들의 렬이며 론리 적변위/길 이/ 
물리 적주소를 포함하는 3 중구조에 의하여 서술된다. 주소화된 구조는 범위서 술자에 의하 
여 3 중다중화되 고 색 인마디 에 뿌리 로 보존되 며 파일안의 론리 적편위 에 의하여 열쇠화된 
B+ 나무이 다. 

JFS 에서 B + 나무의 광범한 리용 

이 부분에 서 는 파일의 륜곽적 구조에 리용되 는 B+ 나무구조를 서 술한다. JFS 에서 진행 
되여야 할 가장 공통적인 조작들 즉 범위의 읽기，쓰기성능을 높이기 위하여 B + 나무를 
선택한다. B+ 나무는 또한 파일의 범위를 효과적 으로 첨 가 혹은 삽입할수 있는 기능도 제 
공한다. 

좀 일반적이기는 하지만 JFS 에서는 B+ 나무에 리용된 블로크들뿐아니라 파일자료를 
제거하였는가를 확인하기 위하여 파일제거시 전체 B+ 나무를 조사해 야 할 필요가 제 기된 
다. B+ 나무는 또한 추적에도 아주 효과적이다. 범위배정서술자 (xad 구조체)는 범위를 서 
술하며 파일을 표시하는데 요구되는 두개이상의 마당들을 첨가한다. 이러한 마당으로는 
범위 를 표현하는 론리 적바이트주소를 서 술하는 변위 와 기 발마당을 들수 있다. 범위배정서 
술자구조체 는 linux\indude\JFS\JFS_xtree.h 에 struct xad 로 정 의 된 다. 

여기 에는 등록부를 제외 하고 JFS 의 모든 첨수객체들을 위한 한가지 일반적 B + 나무첨 
수구조체 가 있다. 첨수화되 는 자료는 객체 에 의존하며 B+ 나무는 나무에 의하여 서술되는 
xad 자료의 변위 에 의하여 열쇠화된다. 입 구점 들은 xad 구조체 의 변위 에 따라 정 렬된 다. 
xad 구조체는 B+ 나무의 한개 색 인마디 에 있는 입구점 이 다. 

일단 색 인마디 에 8 개의 xad 구조체가 채워 지게 되면 보다 많은 구조체 에 관하여 색 
인마디 의 마지 막《 상한》을 리용하려 는 시 도도 있다. 만일 색 인마디 의 di_mode 마당에 
mUNEEAbit 가 설정 되 면 색 인마디 의 마지 막상한을 리 용할수 있다. 만일 색 인마디의 리 용 
가능한 모든 xad 구조체 가 다 리용되 면 B+ 나무는 분리 되 여 야 한다. 

디스크색 인마디의 두번째 부분의 아래쪽은 색 인마디의 두번째 절반부분에 무엇 이 기 
억되여 있는가를 알려 주는 자료서술자가 포함되여 있다. 두번째 절반부분이 충분히 작 
다면 파일 에 대 한 직 결자료를 포함할수 있다. 만일 파일자료가 색 인마디 에 관한 직결 자 
료에 정합되지 않으면 범위에 포함되며 색인마디는 B + 나무의 뿌리정점을 포함하게 된다. 
머 리부는 몇개의 xad 가 사용중에 있으며 몇 개 가 리용가능한가를 지적한다. 
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일반적으로 색 인마디는 B + 나무의 뿌리 에 대 하여 8개의 xad 를 포함한다. 만일 파일에 
대하여 8개나 그보다 적은 범위가 있으면 이 xad 구조체들은 B + 나무의 잎마디로 되며 범 
위 를 표현 한다. 그렇 지 않으면 색 인마디 의 xad 구조체 들은 잎 들을 지 적하든지 혹은 B + 나 
무의 내 부마디 를 지 적하게 된 다. 

잎 마 디 

피크는 B + 나무의 잎 마디 에 4 KB 의 디 스크공간을 배 정한다. 잎 마디 는 머 리 부를 가지 는 
xad 입구점들의 배렬이다. 머리 부는 마디의 첫 번째 빈 xad 입구점을 지적 하며 배정되지 않 
은 입 구점 다음의 모든 xad 입 구점 들을 제 거한다. 8개 의 xad 입 구점 들은 색 인마디 로부터 입 
구점 에 복사되 며 머 리 부는 첫번째 빈 입 구점 으로서 아홉번째 입 구점 을 지 적 하기 위하여 
초기 화된 다. 다음 B + 나무의 뿌리 를 색 인마디 의 첫번째 xad 구조체 로 갱 신하는데 이 구조 
체 는 새 로 배정된 잎마디 를 지 적한다. 

이 새로운 xad 구조체 에 대한 변위는 잎마디의 첫번째 입구점의 변위로 된다. 색 인마 
디안의 머 리부는 현재 하나의 xad 만 사용되 고 있 다는것 을 지 적 하기 위하여 갱 신되 게 된 
다. 머 리부도 또한 색 인마디 가 현재 순수 B + 나무뿌리 를 포함하고 있 다는것 을 지 적 하기 
위하여 갱 신되 여 야 한다. 

새 범위들이 파일들에 보충되므로 마디가 채워 질 때까지 순서대로 갈은 잎마디에 
계 속 보충되 게 된 다. 이 런 견지 에 서 4 KB 의 새 로운 디 스크공간이 다른 잎 마디 에 의하여 
배정되며 그 색 인마디 로부터 두번째 xad 구조체 가 새 롭게 배정된 이 색 인마디 를 지 적할수 
있게 설정된다. 이러한 과정은 8개의 구조체가 색인마디에 다 채워 질 때까지 계속 진행 
되며 이때 B + 나무의 다른 뿌리부분이 생성된다. 이 갈라 진 부분은 순수 나무의 람색을 
추적하는데만 리용되 는 B + 나무의 내 부마디 들을 생 성하게 된 다. 

내 부 마 디 

피크는 B + 나무의 내 부마디 를 위하여 4 KB 의 디 스크공간을 배 정한다. 내 부마디 는 잎마 
디와 꼭 같이 볼수 있다. 잎마디를 가지고 있기때문에 8개의 xad 입구점들은 그 마디로부 
터 내 부마디 로 복사되 며 머 리 부는 9번째 입 구점 을 지 적할수 있게 초기 화된 다. 

다음 JFS 는 색 인마디의 첫 xad 구조체 가 새 로 배정된 내부색 인마디를 지적할수 있게 
함으로써 B + 나무의 뿌리 를 갱 신한다. 색 인마디의 머 리부는 B + 나무에 오직 한개의 xad 가 
리 용되 고 있 다는것 을 지 적 할수 있 도록 갱 신된 다. linux \ include \ linux \ JFS \ JFS _ xttee . h 파일 은 
구조체 struct xtpage _ t 의 B + 나무뿌리 에 대 한 머 리 부를 표시 한다. linux \ include \ linux \ 
JFS \ JFS _ bttee . h 파일 은 구조체 struct btpage _ t 에 있 는 잎 마디 든가 혹은 내 부마디 를 위 한 머 
리 부이 다. 

가변블로크크기 

피크는 매 파일체 계당 512, 1024, 2048, 4096 byte 의 블로크크기를 지원한다. 이것은 사용자 
가 응용프로그람실행환경에 기초하여 공간리용을 최량화할수 있게 한다. 블로크크기를 작게 
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하면 등록부나 파일 안에 내부토막의 수가 작아 지므로 효과적 인 공간적성능이 엄 어 진다. 
그러 나 작은 블로크들을 리용하면 큰 블로크크기를 리용할 때보다 블로크배정동작이 더 자 
주 진행되기때문에 경로의 길이가 길어 지게 된다. 봉사기에서는 공간적리용보다 오히려 
성 능상의 문제 가 선차적 인 고려 대 상으로 되 기때 문에 기정 블로크크기 는 4096 byte 로 제 한한다. 

JFS 는 공간이 더 이상 필요하지 않을 때에는 그것을 개방하여 요구되는것만큼 디스 
크색 인마디공간을 배정한다. 이 방법은 파일체계생성시 에 고정된 디스크색 인마디공간을 예 
견하지 않아도 되게 하며 따라서 파일체계 가 포함하는 파일과 등록부의 최대수를 평 가하 
지 않아도 된다. 또한 이 방법은 고정된 디스크위 치 로부터 디스크색 인마디들을 분리시 킨다. 

등록부조직 

JFS 에는 두개의 서로 다른 등록부조직방법이 있다. 

첫 번째 조직 방법 은 작은 등록부들에 리용하는데 등록부의 내 용을 등록부의 색 인마디 
에 기억한다. 이 방법은 등록부블로크 I/O 를 분리시킬 필요성뿐아니라 기억을 분리하여 
배정할 필요성도 느끼지 않게 한다. 8개까지의 입 구점 들이 색 인마디안에 즉시삽입방법으 
로 기 억 될수 있 으며 자기 자체 (.) 와 상위 (..) 를 제 외 하고는 따로따로 된 구역 에 기 억 된다. 
두번째 조직 방법 은 보다 큰 등록부들에 리용되 며 매 등록부는 이 름에 관하여 열 쇠화된 
B + 나무로써 표현된다. UNIX 등록부와 마찬가지로 Linux 등록부는 Is 명 령에 스위 치 ” 4” 
를 리용하여 찾아 볼수 있 다. 이 조작은 전통적 인 비 정 렬 등록부조직 방법 과 비 교할 때 등 
륵부고속검 색，삽입，삭제능력 을 제 공한다. 

성긴과일과 밀집과일에 대한 JFS 의 지원 

피크는 매 파일체계에 기초하여 성긴파일+과 밀집파일을 지원한다. 성긴파일은 파일 
블로크가 장애로 인하여 씌여 지지 않았다는것을 먼저 검증하지 않고도 자료를 임의의 
위치에 써넣을수 있게 한다. 알려 진 파일크기는 리용한 바이트수로는 제일 높지만 파일 
에 주어 진 임의의 블로크의 실지적배정은 쓰기조작이 그 블로크우에서 완성될 때까지 
발생하지 않는다. 실례로 성긴파일로 설계된 어떤 파일체계에 새로운 파일이 생성되였다 
고 하자. 응용프로그람은 파일안의 100개 의 블로크에 한개 자료블로크를 쓴다. JFS 는 디 
스크공간상의 한개 블로크가 파일에 배정되였지만 파일의 크기가 100개 블로크라고 통보 
한다. 만일 응용프로그람이 파일의 블로크50을 읽는다면 피크는 값이 모두 0인 한개의 블 
로크를 귀환시킬것이다. 다음 응용프로그람이 파일의 블로크50에 한개의 자료블로크를 
쓴다고 가정 하자. 피크는 역시 이 파일의 크기를 여전히 100개 라고 통보할것 이며 이때 디 
스크공간의 두개 블로크가 파일 에 배정 된다. 성 긴파일은 대 규모의 론리공간을 요구하지 
만 이 공간의 부분모임 만을 리용하는 응용프로그람에 서는 흥미 있는 문제 로 된 다. 


모든 첨 수들은 제 일 좋은 대 기렬 성 능을 얻 기 위하여 기 억안에 보존된 다. 이 경 우에 S.B 우의 성 
긴첨 수들은 모든 열쇠 들이 그 성긴첨 수안에 나타나지 않기때 문에 밀집첨 수보다는 좋지 못하다. 
밀집파일에서는 디스크자원들이 파일의 크기를 포함할수 있게 배정된다. 


262 





앞의 실례 에서 첫번째 쓰기 에서는 파일 에 배정될 디 스크공간의 블로크수가 100으로 
엄어 질것이다. 암시적으로 씌여 진 어떤 블로크상에서의 읽기조작은 성긴파일의 경우와 
곡 같이 모든 값이 0인 블로크를 귀환시 킬것 이 다. 

집합과 파일모임 

JFS 의 용어중에 는 집 합과 파일모임 이 라는 표현이 있는데 이 절에서는 이 용어 들에 
대하여 고찰하게 된다. 

과 일 

파일은 B+ 나무의 뿌리 를 포함하는 색 인마디 에 의하여 표현된다. 이 때 B+ 나무는 
사용자자료를 포함하는 범위를 서술한다. B+ 나무는 범위의 변위에 의하여 첨수화된다. 

등록 부 

JFS 등록부에 는 가동일 지화된 메 타자료파일 이 있 다. 

UNIX 등록부와 같이 Linux 등록부는 곧 파일의 잎이름과 색인마디번호사이의 관계이 
다. 파일의 색 인마디번호는 ls 명 령 에 ” -i” 스위 치 를 리용하여 찾아 볼수 있다. 

등록부는 포함된 객 체 들을 지 적하는 등록부입 구점 들로 구성 된 다. 

등록부입 구점 은 이 틈을 색 인 마디 번 호와 련 결 하며 정 의 된 색 인 마디 는 정 의 된 이 름을 
가진 객체를 표현한다. 특정한 등록부입구점 을 지 적 하기 위한 능력 을 제 공하기 위하여 
이 름에 의하여 정 렬된 B + 나무가 리 용된다. 

등록부색 인마디의 di_ s iz e 마당은 바로 등록부 B+ 나무의 잎페지들을 표현한다. 등록부의 
잎마디 들이 색 인마디안에 포함될 때 di_size 의 값은 256 으로 된 다. 등록부는 자기 자신 (” ) 
과 상위 (” ) 들에 대 한 특정한 입 구점 들을 포함하지 않는다. 대 신 이 것 들은 색 인마디 자체 
에 표현된 다. 자기 자신이 라는것 은 등록부자체 색 인마디 번호를 말하며 상위 라는것 은 색 인마 
디 에 특별한 마당 즉 linux\ include\linux\IFS\JFS_dtree.h 파일의 idotdot, stru 功 dttoot_t 을 말한다. 

등록부색 인마디는 일반정규파일과 류사한 방식의 B + 나무뿌리를 포함하며 이름에 의 
하여 열쇠화된다. 등록부 B + 나무의 잎마디 는 등록부입 구점 을 포함하며 완전한 입 구점이 름 
으로 열 쇠화된 다. 

등록부 B + 나무는 B + 나무의 마지 막내 부마디 에 관하여 뒤불이 압축을 리용한다. 나머 지 
내 부마디 들은 동일 한 뒤불이압축을 리용한다. 뒤불이압축은 선행입 구점 으로부터 현행입 구 
점을 구분할만큼 충분한 문자수로 이름을 제 한한다. 

가동 일지 

JFS 가동일지는 매 개 집 합안에 보존되며 메 타자료조작에 대 한 정보를 기록하는데 리 
용된다. 가동일지 는 파일체 계 생성편의프로그람에 의하여 설정 되 는 양식 을 가진다. 단일 가 
동일 지는 집 합안의 다중올려태 우기 된 파일 모임 에 의하여 동시 에 리용될 수 있 다. 가동일 
지 에 기초한 몇 가지 회복측면은 아주 흥미 있다. 

첫째로 피크는 오직 메타자료에 관한 조작만을 등록한다. 
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그리 하여 가동일 지 만을 재 현시 키 는 방법 으로 파일 체 계 안의 구조적 관계 의 일 관성 과 자원배 
정상태를 회복한다. 이 방법은 파일자료는 가동일지에 기록하지 않으며 일관성상태에 대한 자 
료만 회복한다. 동시에 일부자료파일들은 잃어 질수도 있고 회복후에 정상이 아닐수도 있으며 
따라서 자료의 일관성에 대한 요구가 강한 사용자들은 동기식】/0를 리용해야 한다. 

가동일지기능은 매체에 오유가 발생할 때에는 특별한 효과가 없다. 특히 디스크에 가동 
일지나 메타자료를 쓰는 과정에 생기는 I / O 오유는 시간소비를 없애고 체계의 폭주후에 파일 
체계를 정상상태로 회복하기 위하여 잠재적인 장애를 집중적으로 완전히 검사하여야 한다. 
이것은 불량블로크재배치가 어떤 기억관리기나 JFS 의 토대장치들의 기본특성으로 된다. 

JFS 가동일 지기 능은 메 타자료에 대 한 변경 (실 례 로 unlink ()) 을 포함한 파일 체 계 의 조작 
이 귀환코드를 성과적으로 돌려 줄 때 조작효과성이 파일체계에 통보되며 설사 체계가 
폭주된다고 해도 알려 지게 하는것이다. 실례로 파일이 일단 성공적으로 제거되면 그 파 
일은 체계가 폭주되여 재시동할 때 다시 나타나지 않게 된다. 

이러한 가동일지등록형식은 매개 색인마디나 메타자료를 변경하는 VFS 에 가동일지 
디스크에 대한 동기적쓰기를 도입한다(자료기지 숙련자에게 있어서 이 조작은 비절취완 
충기 방법 을 리용하는 반복작업，물리 적잔상，미 리쓰기 가동일 지등록규약 등이 다.). 성 능상 
견지 에 서 보면 이 조작은 일 관성 을 위하여 다중동기메 타자료쓰기 에 의 존하는 많은 비실 
행 기 록파일체 계 와 비 교되는 정 도이 다. 그러 나 다른 실행 기 록파일체 계 즉 Veritas VxFS 와 
Transarc Episode 와 같은 실행 기 록파일계 에 비 해 보면 성 능상 부족점 이 있다. 이 체 계들은 
서 로 다른 가동일지기 능형 식 을 리용하며 가동일지자료를 디스크상에 서서 히 기록한다. 
다중병 렬조작을 수행하는 봉사기 환경 에 서 이 성 능비 는 다중동기쓰기조작을 단일쓰기조작 
과 결 합하는 그룹위 임 에 의 하여 감소된 다. JFS 의 가동일 지 등록형 식 은 상당히 개 선되 였 으 
며 현재 는 비동기적 가동일지등록을 제 공하는데 이 것은 파일체 계의 성 능을 제 고한다. 

과일구조와 접근조종 

만일 어떤 방법 으로 파일을 유연성 있게 조종하여 여 러 사용자들에 게 공유시키 려면 
여러가지 안전한 방식들이 요구된다. 

이 요구는 다음과 갈은 내용들을 포함한다. 

▼ 다른 사람으로 가장한 침 입자로부터 보호하는것 

• 특별 하게 접 근이 허 용된 사람들에 의한 사고나 고의 적 인 행동으로부터 보호하는것 

• 특별히 접근이 금지된 사람의 고의적 인 행동이나 파괴행위로부터 보호하는것 

• 자기 자신에 의하여 초래된 파괴 로부터 보호하는것 

• 필요하다면 한명의 사용자 혹은 사용자그룹에 의 하여서만 접근이 허용되는 완전 
비 공개 성 

• 장치 혹은 체 계프로그람의 오유나 고장으로부터 의 보호 

• 인증되지 않은 사용자에 의한 간섭 으로부터 체 계의 안전성 을 자체 로 보호하는것 

▲ 다른 보호수단들의 지나친 응용으로부터 보호하는것 

다음 장들에서 Linux 의 일반개념으로서 보호문제가 어떻게 실현되며 개별적파일체계 
들에 어떻게 적용되는가에 대하여 서술한다. 
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제 9 장. Linux 용 Reiser 파일체계 

가장 오랜 Linux 용실 행 기 록파일 체 계 들중의 하나는 ReiserFS(Reiser 파일 체 계 )이 다. 이 
대 상과제 는 한스 Reiser (Hans Reiser) 에 의 하여 개 발되 였 다 . 

ReiserFS 는 설계와 프로그람구성에 있어서 우수한것이지만 다른 비 Linux 구성요소들 
과의 련관성 이 부족한 결함도 가지고 있다. 

ReiserFS 의 기본목적은 폭주후에 회복시간을 최대로 줄이며 업무처리에서 파일체계 
의 메 타자료를 갱신할수 있게 하는것 이 다. ReiserFS 는 고속이며 특히 소규모파일과 많은 
파일을 포함하고 있는 등록부에 대해서도 역시 속도가 빠르다. 

앞으로의 목표는 전원투입시 보호목록을 가지 는 원래 의 파일체 계 만큼 빨리 예 비 쓰기 
가동일 지 등록을 수행 하게 하는것 이 다. 

이 장에서는 ReiserFS 설계와 개 념의 구체적측면뿐만아니 라 설치와 관리 등과 같은 
보다 실천적 인 문제들을 취급한다. 

파일체계의 이■공간 

ReiserFS 의 중심적개념들중의 하나는 유일화된 이름공간이다. 한스 레이져는 《파 
일》과 등록부의 두 객체를 다 포함하는 파일체계를 만들려고 하였다. 

실례를 들어 설명하기 위하여 bmoshe 는 사용자이고 bmoshe/mail 은 우편통이며 
bmoshe / mail / Message - ID /20000615091245. A 2500@ moshebar . com 은 전 자 우 편 이 며 
bmoshe / mail / Message - ID /20000615091245. A 2500@ moshebar . com / tO ^- TO 이 라고 하겠 
다.즉 해 당한 e-mail (전자우편)의 머 리부마당이 다. 그룹들과 결 합하여 전화상에 서 
Avivit 의 모든 e-mail 을 찾기 위 하여 mail /[ form/avivit phones ] 를 검 색 할수 있 어 야 
한다. 이러한 유일화되고 닫겨 진 이름공간은 프로그람작성 특히 객체지향프로그람작성 
을 쉽게 하는데서 커다란 영향력을 가진다. 다음의 명령에서 알수 있는바와 같이 매개 
객체는 그것의 마당접근자와 부분이름과 갈은 어음변화조작을 가지는 그자체의 이름짓기 
문맥으로 자연스럽게 생각할수 있다. 우의 실례를 의역하면 다음과 같이 된다. 

moshe.getMailBox().getMessageByID("200006 1509 1245@moshebar.com") 

플랜 9(Plan 9) 와 인퍼 노 (Inferno) 조작체 계 들과 같이 잘 알려 진 체 계 들은 분명 히 류 
사성을 가진다.한스 레이져가 제기한바와 같이 유일한 이름공간은 하나도 없지만 
li everything-is-a file” 이 라는 개 념은 좀 생각해 볼 필요가 있다. 하지만 그가 제기 한 파 
일체계 에 대 한 추상화는 여 전히 개 념상 몇 가지 의 문스러 운 점 들도 가지 고 있다. 무엇보 
다도 속성의존문제 는 속성 이 객체 가 아니 라는데 로부터 성 립하지 않는다. 

사실상 속성은 객체의 마당이 아니 다(설사 속성 이 그러한 마당들을 드러 내 보일수도 
있지만). Reiser 의 그룹화와 순서화의 통일문제는 아주 어려운 문제라는것을 알수 있게 
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한다. 레이져가 제기한것처럼 초의미적문법은 가능한 모든 요구에 대하여 관리가능한 몇가 
지 렬을 선정하는것 이 다. 일반화，집합，분류 그리고 관계는 is-a, has-property, is-an- 
instance-of, isnnember-of 렬에 각각 대응한다. 레이저가 제기한 문제는 속성을 알려면 
그 관계 를 알아야 한다는것 이 다. 레 이저의 실례 를 리 용하여서 는 추진-공급 (propulsion- 
provider-for) 관계를 우에서 설명 한 정규관계 로 어떻게 분해 하는가를 모르는 이상 속성 을 
알아 낼수 없다. 

이로부터 이름공간의 통일과 닫김에 대하여서는 더 연구하여야 한다. 생성체계에 관 
한 ReiserFS 를 리 용할수 있 으며 또 효과적 이 라는것 을 알고 있 지 만 아직 도 proof-of- 
concept 파일 체 계 와 research-anc 卜 development 도구를 리용하고 있 는데 이 것돌은 그 어 떤 
의미 에 의하여 생성된것은 아니 다. 

이제 ReiserFS 의 몇 가지 기술적설계 개 념을 더 연구해 보자. 

파일경계의 블로크정돈 

ReiserFS 는 디스크상에서 블로크들로 파일 경계들을 정돈한다. 이것은 몇가지 리 유 
로부터 설 명할수 있다. 즉 블로크의 수를 최 소화하기 위하여 파일 의 량단을 넓 힌 다(이 
것 은 파일 의 량끝점 위 치 가 불투명할 때 다중블로크파일 들에 대 하여 특별 히 효과적 이 
다.). 이것은 디스크나 완충기에 완전히 채워 지지 않은 블로크들을 기억시킴으로써 있 
을수 있는 랑비를 피하는것，기준장소가 정해 졌을 때 역시 다 채워 지지 않은 블로크 
에 대하여 개개의 접근으로 대역폭의 랑비를 없애는것，등록부안의 매 파일에 접근하 
기 위하여 요구되 는 평 균선행불러 내 기블로크수를 줄이는것 등인데 보다 간단한 코드로 
실 현 할수 있다. 

보다 간단한 파일체 계의 블로크정 돈 코드는 디 스크조종장치 의 단위 를 구분하기 
위하여 계 층화할 때 , 공간배 정 으로부터 알고리 듬을 완충화할 필 요가 없을 때 또한 균 
형나무알고리듬에서 고찰한바와 같이 마디들의 묶음을 최량화하지 않아도 될 때 필요 
하다. 

한스 레 이저는 디스크공간의 랑비를 피 하기 위하여 처 음부터 작은 파일들을 집 합화 
하려 고 했다. 제 일 간단한 해결방법은 등록부안의 모든 파일들을 한개 파일 이 나 혹은 한 
개 등록부에 집 합시키 는것이 였 다. 

하지 만 한개 파일 이 나 등록부로 집 합시키 는 문제 는 집 합의 마지 막블로크부분을 랑 
비한다. 한개 등록부안에 몇개의 작은 파일들이 있으면 그것들을 등록부의 상위 에 어 
떻 게 집 합시 키 겠는가 하는것 이 다. 처 음에 한개 등록부에 몇개의 작은 파일만이 있고 
다음에 많은 파일들이 있으면 OS 는 그것 들을 집 합시키 는데 어 느 준위 를 리용하겠는가 
에 대하여 결심하며 어느 때 그것들을 상위등록부로 돌려 보내며 등록부에 직접 기억 
시키겠는가? 

물론 이 문제 는 균형 나무에서 마디 의 균형 화와 밀접한 관계 가 있 다. 균형 나무방법 을 
리용하면 동적 으로 집 합된 순서 화된 파일 들을 보다 낮은 준위 의 마디 로 리용하므로 정 적 
집 합이 나 그룹화에서 제기된 질문들을 피할수 있다. 
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ReiserFS 방법에서 파일이나 등록부는 다같이 균형나무에 기억된다. 균형나무는 작은 
파일，등록부입구점，색 인마디 그리고 큰 파일의 마지막꼬리부분과 함께 매 개 요소들이 
블로크정돈에 대한 요구를 낮추게 함으로써 더 효과적으로 묶어 질수 있게 하며 색인마 
디들에 대 하여 고정 된 공간배 치 의 리용을 없 앨 수 있 게 한다. 

균형알고리 듬에 의하여 큰 파일 들의 본체 는 나무에 첨 가한 양식 화되 지 않은 마디 
들에 기억되지만 효과적이며 가능한 이동기능은 떨어 진다. NTFS 와 XFS 도 집합파일 
은 쓰지 않는다. 이 체계들은 정합될만큼 충분히 작으면 정적으로 배정된 색인마디의 
블로크주소마당에 적은 파일들을 기억시키는 한이 있더라도 블로크들을 파일별로 정 
돈시 킨 다. 

모두가 서 로 다른 립도를 가지 는 의 미 론(파일 )，묶음화(블로크/마디 )，고속완충기억화 
(선행읽 기크기)디 스크들의 장치적 대 면부와 페 지 화는 서 로 련관된 론제 로 제 기 된다. 흔히 
이 와 같이 립도가 서 로 다르다는것 을 리해 하고 그것 들을 한개 층이 다른 층들에 강하게 
영향을 주지 않는 개개의 층으로 추상화함으로써 공간/시간성능을 개선해 나갈수 있다. 
ReiserFS 는 의 미 론적 계 층이 비 립 도화된 순서 화를 파일 경 계 에 의 하여 립 도화된 계 층으로 
이 전시키 는데 서 일 정하게 전 진 하였 다. 

ReiserFS 의 코드알고리 듬을 읽 으면서 ReiserFS 를 더 전진시키 는데 필 요한 령역 들을 
리해하는 문제 가 제 기된다. 

균령나무와 대규모파일 I/O 

fo 효과성과 대규모파일들의 블로크크기사이의 호상작용을 리해하는것은 아주 복잡한 
문제 이며 이때 공간은 전통적 인 체계고찰방법으로는 취급할수 없다. 

ReiserFS 에 는 공간기 억 을 위한 재묶음휴지시 간이 초래 되 기 때 문에 블로크를 크게 하 
여 야 하는 구성 방식상의 취 약성 이 동반된다. 

▼ 파일의 꼬리 (4KB 보다 작은 파일들은 모두 꼬리가 있다.)가 전체 색인마디를 차지 
할만큼 커지게 할 때 양식화된 마디 로부터 비양식화된 마디 로 변환된다. 

• 한개 마디 보다 더 작은 꼬리 는 두 마디사이 에 퍼질 수 있 으며 이 때 두개 마디 의 
기준위 치 가 불량하면 보다 많은 I / O 를 요구하게 된다. 

• 한개 마디 로 다중꼬리 들을 집 합하는것은 꼬리 로부터 파일의 본체를 분리시키는 
결 과를 초래하며 이 때 읽 기 성 능이 떨 어 진다. 크기 상으로 마디 와 가까운 ReiserFS 
에서는 영 향이 현저하게 나타난다. 

▲ 양식화된 마디 의 마지 막항목이 아닌 파일 이 나 꼬리 에 한개 바이 트를 추가할 때 
평균적으로 전체 마디의 절반이 기억에 옮겨 진다. 

어떤 응용프로그람이 몇개의 작은 완충화된 쓰기방식을 안정시키는 방법 으로 I / O 를 
수행할 때 ReiserFS 는 I / O 를 완충시키 지 않게 하는데 많은 비 용이 든다. 

실재하는 파일 체 계 적 재 를 실 현 하는 대 다수의 응용프로그람들은 표준 C 언 어 서고의 I/O 
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함수들을 리용하여 I/O 완충기화를 아주 단순하고도 효과적 으로 실 현 하고 있 다. 

작은 블로크/범 위 에 대 한 접 근을 피 하기 위 하여 ReiserFS 는 I/O 의 효과성 을 개 선하고 
있 다. VFS 와 같이 크기 에 기 초한 파일 체 계 와 ex 任 fs 와 같이 쓰기 -콜라스터 형파일체 계 들은 
기 정 값으로 주어 진 1K 블로크보다 512byte 블로크를 선택 하여 리 용할 때 효과성 이 높지 
못하다. ext2fs 는 化를 리용할 때보다 4K 를 리용할 때 28% 정 도 속도가 높다. 

하지만 ext2fs 의 개발자들은 공간랑비를 없애기 위하여 1K 블로크를 리용할것을 요구한다. 

ext2fs 나 ReiserFS 에 보충할수 있는 가치 있는 대규모파일최량화방법이 있다. 이러한 
견지 에서 두 파일체계 는 어느것 이든지 원시적 이며 그중에서도 ReiserFS 가 좀 더 원시적 
이라고 볼수 있다. 

ReiserFS 에 는 블로크크기 를 증가시 키 는 방법 외 에 대 규모파일 에 대 한 가치 있는 최 량 
화수법이 없다. 

블로크크기 를 제 외 하고는 다음의 것 들사이 에 본질 적 인 차이 가 없 다. 

▼ 나무에 마디 쓰기 를 보충한 비양식 화된 마디 에 대 한 지 적자를 첨 가하는 비 용 

▲ 색인마디의 블로크쓰기를 보충한 주소마당의 첨가 

블로크크기 를 제 외 하고 고성 능대 규모파일체 계 의 1차적결정항목은 중소규모의 균형 나 
무를 파일 에 리용하겠는가를 결정하는 항목과 같다. 

대규모파일들에 대해서는 3 중간접블로크를 지적하는 색인마디에 의하여 형성되는나 
무보다 더 균형화된 나무를 가지지 않는다는 우점 이 있다. 소규모파일에서는 균형마디 들 
의 기 억 대 역비 용으로 인하여 성 능상 휴지 시 간이 존재한다. 

직렬화와 일관성 

최 소직 렬화와 자료치 환으로 회 복기능을 보장하는 문제 는 불가피 하게 고성 능설 계문제 
를 특징 짓게 된다. 이제 직렬화에서 나서는 두가지 극단적인 문제를 정의하여 이러한 근 
거 가 명백해 지게 할수 있다. 모임의 매 블로크요청 이 핵심부의 승강기알고리듬*과 선행 
요청의 완성을 기다리는 디스크구동기점 웨어 (firmware) 에 직렬로 주어 지는 I/O 모임의 상 
대 적 속도를 고찰하자. 이 제 모든 블로크요청 이 승강기알고리 듬에 주어 지 고 다음 그것 이 
모두 정돈되며 정돈된 순서로 수행되도록 하는 한가지 극단을 고찰하자. 직렬화되지 않 
은 한가지 극단에 서는 순환과 찾기 에 드는 비 용으로 크기 를 더 빨리 순서 화할수 있 다. 
불필요하게 직 렬 화된 I/O 는 승강기알고리 듬이 모든 I/O 의 배 치작업 을 년대순으로 보다도 
배 치순으로 할수 없게 한다. 대다수의 고성능설계들에서는 I/O 조작이 디스크상에서의 구 
조적배 치순서 와 발표된 순서 로 진행 되 게 하는데 로 집 중되 고 있 다. 

ReiserFS 는 회 복성 을 보장하기 위 하여 보존목록 (preservelist) 이 라는 새 로운 도식 을 받 
아 들이고 있는데 이것은 새 로운 메 타자료의 쓰기 에 의하여 변경된 메 타자료의 중복쓰기 
를 피하게 한다. 


승강기알고리 를■寒 디 스크에 대 한 I/O 조작을 계 획 화하는 핵 심 부안의 프로그람이 다. 
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나무의 정의 


균형나무를 응용프로그람에 의하여 정의된 열쇠들의 모임이라고 하면 나무의 설계목 
적 은 이 열 쇠 에 의 한 람색 을 최 량화하는것 이 다. ReiserFS 에 서 나무의 목적 은 참조위 치 와 
공간적이며 효과적 인 객체의 묶기를 최 량화하는것 이며 이때 열쇠는 알고리 듬에 따라 정 
의된다. 열쇠는 파일체계 안의 색인마디번호대신에 리용되며 따라서 색인마디번호를 파일 
위치로 넘기기하는것보다 오히려 열쇠의 마디위치(내부마디)로 넘기기를 한다. 열쇠는 색 
인마디번호보다 길지 만 하나이상의 파일 이 한 마디 에 기 억될 때 는 고속완충되 는데 필요 
한 열쇠길이가 오히려 더 짧다. 

ReiserFS 나무는 파일이름이 어느 한 순간에 한개의 성분을 해결 할것을 요구한다. 이 
요구는 이름이 필요한지 혹은 최량적인지를 앞으로 더 연구하는데서 하나의 문제점으로 
된다. 이 문제는 그것을 실현하는것보다 더 복잡한 론의점이다. 어느 한 순간에 등록부검 
색은 한가지 압축형식을 완성하게 되는데 이것은 다른 이름공간의 올려태우기와 체계확 
장자，안정 성 그리 고 보다 확장강화된 의 미 론적문법 을 더 단순하게 한다. 파일 을 작게 
취 하면 등록부가 커지 기때 문에 나무알고리 듬을 리용하는 이 등록부기술이 대 규모적 인 등 
록부에 대하여 대다수 다른 파일체계들보다 훨씬 더 효과적인것으로 되였다. 나무는 3개 
의 마디형식을 가진다. 하나는 내부마디이고 다른 하나는 양식화된 마디이며 또 다른 하 
나는 양식화되지 않은 마디이다. 내부마디와 양식화된 마디는 열쇠의 순서로 정렬된다(양 
식화되 지 않은 마디 는 열쇠 를 포함하지 않는다.). 

내부마디 는 경 계열쇠 에 의하여 분리 되 는 부분나무에 대 한 지 적자를 포함한다. 부분 
나무에 대한 지적자보다 앞서 있는 열쇠는 그 부분나무의 첫번째 양식화된 마디에 있는 
첫 중복열쇠 이 다. 내 부마디 는 양식화된 마디 가 열쇠 에 대 응하는 항목을 포함하는가를 결 
정하는데 쓰인다. 

ReiserFS 는 뿌리 마디 로부터 출발하여 내 용을 검 열 하며 부분나무가 요구된 열쇠 에 대 
응하는 항목을 포함하는가를 결 정할수 있다. 뿌리마디 로부터 ReiserFS 는 매 개 마디 에 서 
갈라 지 면서 요구되 는 항목을 포함하는 양식화된 마디 에 도달할 때 까지 나무를 따라 아 
래로 내려 온다. 

나무의 첫번째(바닥) 준위는 양식 화되지 않은 마디를 포함하며 두번째 준위는 양식 화 
된 마디 를 포함하며 그우의 모든 준위 는 내 부마디 를 포함한다. 제 일 높은 준위 는 뿌리마 
디 를 포함한다. 준위 수는 나무의 득대 기 에 새 로운 뿌리마디 를 요구되 는만큼 첨 가함에 따 
라 증가하게 된다. 

나무의 뿌리로부터 양식화된 모든 준위까지의 모든 경로는 길이가 같다. 양식화되지 
않은 준위까지의 경로도 역시 같지만 양식화된 준위까지의 경로보다는 한마디가 더 길다. 
경 로길 이 에 서 의 이 러 한 등가성 과 그것 을 제 공하는 고속전개 는 고성 능을 얻 는데 서 핵 심 기 
능이 다. 

양식화된 마디 들은 네 가지 형 식 즉 직 접，간접，등록부，상태자료로 된 항목을 포함 
한다. 모든 항목들은 항목을 찾거 나 정 렬시키 는데 사용되 는 유일 한 열쇠 를 포함한다. 직 
접항목은 파일의 꼬리 를 포함하는메 이 꼬리 는 파일 의 마지 막부분이 다. 간접항목은 양식 
화되 지 않은 마디 에 대 한 지 적자를 포함한다. 모든 파일 의 꼬리 는 양식 화되 지 않은 마디 


269 




안에 포함된다. 직접항목은 그 항목안에 첫번째 등록부의 입구점열쇠를 포함하며 그뒤에 
는 많은 등록부의 입구점들이 놓인다. 

파일은 간접항목의 모임을 포함하며 그뒤에는 두마디사이로 갈라 진 꼬리들의 실례 
를 표현 하는 두개 의 직 접항목을 가지 는 2개 까지 의 직 접항목들의 모임 이 놓인다. 만일 꼬 
리가 양식화된 머리부에 일치시킬수 있는 파일의 최대수보다 더 크면서 양식화되지 않은 
마디크기 (4 K ) 보다 작으면 양식 화되 지 않은 마디 에 기 억 되 며 리 용된 공간의 크기 를 합한 
지 적 자는 간접항목에 기 억된다. 

등록부들은 등록부항목들의 모임 으로 구성 되 는데 등록부항목들은 등록부입 구점 들의 
모임으로 이루어 진다. 한편 등록부입구점들은 파일이름과 이름으로 된 파일의 열쇠를 
포함한다. 한개 의 단일한 마디 에 기 억된 같은 객체 에는 동일한 항목형 을 가지 는 하나이 
상의 항목은 존재하지 않는다(결 합된 항목보다 두개 로 분리 된 항목을 리용하려 고 할 리 
유는 없다.). 

균형을 유지하려고 할 때나 마디에 그것의 린접한 마디를 묶는 문제를 해석해 보면 
ReiserFS 는 세개의 마디 를 두개 마디 로 줄일수 없다는것을 시 사해 준다. 

나무의 순서화 

일부 열쇠정의방법은 패 런의 리용에 의 거 하고 있으며 이것 은 파일체 계 를 생성할 때 
여 러 가지 열쇠정의형 식 으로부터 한개를 아무때 나 선택할수 있다는것 을 의미한다. 실례 로 
모든 등록부입구점들을 파일체계의 앞에 묶어 놓겠는가 혹은 파일의 이름에 가까운 입구 
점 들로 묶어 놓겠는가를 결정하는 방법 을 고찰하자. 대 규모파일 에서는 리용패 턴을 가지 
고있는 체계가 등록부의 모든 입구점들을 변경시키는데서 효과적이므로 모든 등록부항 
목들을 함께 선택하여 야 한다. 작은 파일 에 관하여 서 는 이 름이 파일 에 가까와야 한다. 
류사하게 대 규모파일 에 서 정 적자료는 같은 등록부로부터 서 로 다른 정 적자료라든가 혹은 
등록부입구점들을 가지는것은 본체와 따로따로 기 억되 여 야 한다. 

이러한 알고리듬을 리용하는 의미론적문법객체를 완전히 독립적으로 묶어 놓을수 있 
으며 객체의 이 름들에 의하여 결정 되 는것과는 다른 묶음방법 이 더 적 합한 응용프로그람 
도 있을수 있다. 

열소 I 의 구조 

매 개 파일 항목은 구조체 즉 locality _ id , object _ id , offset 로 된 유일 성마당을 가진 열 쇠 
이 다. 기 정 값에 의 하여 locality _ id 는 상위 등록부의 object _ id 이 다. object _ id 는 파일 의 유일 
한 id 이며 객체가 생성될 때 리용되지 않은 첫번째 object _ id 에 설정된다. 이것은 서로 이 
옷에 묶어 지 고 있는 등록부안에 객체 가 성 공적 으로 생성된 결과이며 패런리 용방법의 우 
점 으로 된다. 파일에서 변위는 항목의 첫번째 바이트로 되는 론리적객체안에 있다. 판본 
0.2 에서 모든 등록부입구점들은 그 입구점에 기억된 자체의 개별적열쇠를 가지고 있으며 
매개는 항목별로 서로 구별된다. 현행 판본에서 는 ReiserFS 가 첫 번째 입구점의 열쇠로 되 
는 항목에 한개 열쇠를 기 억하며 이 한개 의 열쇠 로부터 요구되 는만큼 매 개 입구점 의 열 
쇠 를 계산한다. 등록부에서 변위열쇠성 분은 파일 이 름의 첫 4개 바이 트이다. 따라서 수값 
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적인 변위라기보다 사전편찬적인 내용으로 이것을 생각할수도 있다. 등록부항목에서 유 
일 성마당은 첫 4개 바이 트안의 동일한 파일 이 름입 구점 들을 구별한다. 모든 항목들에 서 
유일 성마당은 항목의 형 을 지 시하며 완충기안의 제 일 왼쪽항목에 관하여 나무안에 앞서 
는 항목이 갈은 형이나 객체중에 있는가를 지적한다. 열쇠에 이 정보를 주는것은 균형조 
건을 해석하는데서는 쓸모가 있으나 비등록부항목에 관해서는 열쇠의 길이가 늘어 나게 
되 며 방식적특성 에 의 문을 가지 게 한다. 

매 개 파일은 유일 한 object _ id 를 가지 지 만 객체 를 찾는데서 는 리용할수 없으며 여 기 
에는 오직 열쇠만을 리용할수 있다. object _ id 는 순수 열쇠가 유일한가만을 확인한다. 만 
일 우리가 객체의 열쇠를 변경시키는 ReiserFS 특성을 사용할수 없다면 불변특성을 가지 
며 그렇지 않다면 변경특성을 가지게 된다(이 특성은 NFS 데몬 등에서도 지원된다.). 개 
발자들은 객체 를 식 별하는데 변경열쇠를 리용하는 문제 가 구성 방식적 으로 해 로운 결과를 
초래하지 않겠는가 하는 문제를 가지 고 오랜 기 간 론의하였 다. 한 연구자는 열쇠를 기록 
하는 임의의 객체가 자체복사를 갱신할수 있는 방법을 가져야 한다는 요구가 제기되면 
해 결할수 있 다고 보았다. 

이것 은 object _ id 가 객체 의 의 미 론적표현을 변화시키 지 않으므로 참조위 치 가 매 우 
불명확해 지는 위치에 0 bject _ id 의 넘기기를 캐쉬에 기억해야 하는 현상을 극복하기 
위한 방식도로 된다. 이 연구자는 열쇠 가 명 백하게 변경 되 지 않는 한 첫번째 로 생 성 
된 등록부의 위치를 꾸러 묶는 방법으로 객체들을 묶음화하였다. 이 묶음은 등록부로 
부터 련결이 해제된다고 해도 묶어 진채로 그냥 남아 있게 된다. 이것은 모든 다중련 
결파일들을 기억하는 일부 다른 파일체계와는 달리 명백한 요청이 없이 생성되는 위 
치로부터 옮기지 못하고 두번째 련결이 이루어 질 때 최초의 위치로부터 옮겨야 했다. 
다중등록부와 련결된 파일은 적어도 그 등록부들의 하나에 리로운 위치기준을 얻어야 
한다. 요약하여 말하면 이 방법은 첫째로 같은 등록부로부터 파일들을 배치한 다음 
갈은 등록부로부터 등록부에 관한 통계자료로서 등록부입구점들을 배 치한다. 순서화 
된 서로 다른 등록부로부터의 간격배치는 없으며 같은 등록부안의 모든 등록부입구점 
들은 련속적으로 배치된다는데 대하여 강조해 둔다. 이것은 실제적으로 공통선조를 
가지 는 작은 등록부안의 파일 들을 꾸러 묶지 않으며 선형순서 화를 결정하는데 서 완전 
부분순서 화를 리용하지 않는데 여 기서 는 순수 상위등록부정보를 리용한다. 완전한 나 
무구조에 대한 지식을 리용하는데서 적절한 경우는 FS cleaner 의 실현에 있으며 동적 
알고 리듬에 는 없다. 

나무마디의 균형화는 다음의 순서화된 우선권에 따라 이루어 진다. 

1. 사용된 마디의 수를 최소화한다. 

2. 균형 조작에 의하여 영 향을 받는 마디 수를 최 소화한다. 

3. 균형조작에 의하여 영 향을 받는 캐쉬 에 기 억되지 않는 마디수를 최소화한다. 

4. 만일 다른 양식화된 마디 를 옮기 려 면 우선권순위 에 의하여 옮겨 진 바이 트들을 
최대화한다. 

또한 보다 미묘한 효과들도 있다. 만일 서로 다른 마디다음에 마디를 임의로 놓고 
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무엇이든 효과적으로 묶어 진 마디들사이 라든가 혹은 극단적으로 즉 잘 묶어 졌거 나 혹은 
걸써하게 묶어 진 마디들사이에서 어떤 극단적방략을 취하면 마디들을 더많이 결합할수 
있다. 이때 극단적 인 옮김조작은 내부마디에 대하여서는 적 당치 않다. 

완충화와 보존목록 

ReiserFS 의 0.2 판본은 나무에 서 모든 항목의 이 동을 추적 하는 쓰기 순서 화체 계 를 실 현 
하였다. 이 판본은 항목을 접수한 마디가 씌여 지기전에 항목이 옮겨 진 마디가 씌여 질 
수 없다는것을 확인하였다. 이것은 최근에 생성되지 않은 항목의 루실을 발생하는 체 계 
폭주를 막을수 있 으므로 필 요하다. 이 추적방법 은 이 미 연구되 였 으며 그것 을 강요한 휴 
지 시간은 현재 의 성 능평 가기 준에 의하여 측정할수 없 었 다. 이 다음 판본에 서 항목의 이 동 
을 부분적 으로 변화시 키 고 항목의 형개 수를 증가시 켰을 때 이 코드는 그것 의 복잡성 으로 
하여 조종에 서 벗 어 났다. 이 코드를 보다 더 간단한 도식 으로 바꾸기 위한 연구가 심 화 
된 결 과 전형 적 인 리용패 턴에 서 는 더 좋은 효과가 엄 어 졌 다. 

이 도식은 다음과 갈다. 항목이 마디로부터 옮겨 지면 그것의 완충기가 씌여 질 블 
로크를 변경한다. 그 블로크를 왼쪽 근방의 변경된 블로크들에 대 하여 가장 가까운 자유 
블로크로 변경시키며 그렇지 않으면 그 블로크를 비우고《보존목록》에 변경된 블로크 
번 호를 기 입한다(여 기 서 가장 가깝다는 말은 아주 단순하다. 블로크번 호지 정 함수가 블로 
크번호가 증가하는 영향의 왼쪽근방으로 옮긴다는 의미이다.).《일치순간》이 얻어 질 
때 보존목록의 모든 블로크들을 비운다. 일치순간은 객체가 옮겨 진 기억에 마디가 하나 
도 없을 때 발생한다. 만일 디 스크공간을 벗 어 나면 일 치순간발생 을 요구한다. 이 조작은 
파일 체 계 가 회 복가능하다는것 을 확인 할 때 효과적 이 다. 대 규모파일 의 성 능평 가를 진행 하 
는 동안 성능평가도중에 보존목록이 몇번 비워 졌다는데 대하여 강조해 둔다. 보존된 완 
충기의 퍼센트값은 지우기동안을 제외하고는 실천적으로 작으며 필요한만큼 자주 일치순 
간이 발생할수 있 게 미 리 준비할수 있 다. 

이 방법 은 BSD 의 쏘프트갱 신방법 (Soft Updates approach of BSD) 이 나 ReiseFS 0.2 판 
본에 의한 방법 보다는 좀 못할수도 있 다. 그러 나 그러한 쓰기순서추적방법 은 항목을 부 
분적으로 옮기는 균형 나무에 관한 방법보다 더 복잡하다. 그러 나 ReiserFS 는 1-10K 크기 
의 범위에 있는 파일에 대하여 실제상 성능에 장애가 있을수 있기때문에 앞으로는 변경 
된 알고리듬으로 될것 이 다. 

ReiserFS 구조 

ReiserFS 나무는 Max_Height=N (현재 기 정 값은 N=5) 의 최 대 높이 를 가지 며 디 스크블로크 
에 존재한다. ReiserFS 나무에 속하는 매 개 디 스크블로크는 한개 블로크의 머 리 부를 가진 다. 

파일체계안의 매 객체는 항목의 모임으로 기 억되며 매 항목은 item_head 를 가진다. 
item_head 는 항목의 열쇠와 그것의 빈 공간(간접항목에 대한)을 포함하며 블로크안의 항목 
자체의 위치를 정의한다. 나무의 내부마디를 포함하는 디스크블로크는 열쇠와 디스크블로 
크에 대한 지적자이며 그 형식은 다음과 같다. 
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Block_Head Key Key Key … Key Pointer Pointer ，，• Pointer … Pointer … 빈 공간 
0 12 N 0 1 N N+l ••• 

나무안의 매 개 잎 (잎은 n 개의 항목과 대 응하는 머 리부를 가진다 . )은 다음과 같은 내 
용을 포함하는 디스크블로크를 가진다 . 


Block_HeM lHead lHeM … lHead Point … 빈 공간 Item … Item Item 
0 1 NO". N 10 

또한 우에서 언급한 나무의 양식화되지 않은 마디를 포함하는 디스크블로크도 있다 . 
이 종류의 디스크블로크들은 자료를 포함하는데 밖으로부터는 구조적으로 비여 있는것처 
럼 보인다(자료를 포함하고 있다고 해도 ). 

ReiserFS 의 이 름공간(파일과 등록부를 포함하는)에서 객체의 최 대수는 다음의 방법 으 
로 계산한다 . 

2 32 -4 


이 값은 4,294,967,292^ ^■ 다 . 

내부마디구조 다음의 표에서 는 디 스크상에 기 억될 때 의 색 인마디블로크구조를 보여 
준다 . ReiserFS 색 인마디 는 곧 열 쇠 와 디 스크자료블로크들에 대 한 지 적 자를 기 억 하는 
ReiserFS 나무의 한개 마디이다 . 

Block_Head Key Key Key … Key Point Point Point … Point Point … 빈 공간 
0 12 N 0 1 2 N N+l 

여기서 우리는 열쇠구조에 관한 표현을 볼수 있다 . 모든 변수들은 32bit 크기를 가진 
다는것을 강조한다 . 


마당이름 

형 

크기 (byte) 

설 명 

K_dir_id 

_u32 

4 

상위등록부의 ID 

K_object_id 

_u32 

4 

객체의 正)(색인마디의 번호 ) 

K_offset 

_u32 

4 

객체 의 시 작으로부터 현행바이트 
까지의 변위 

K_uniqueness 

_u32 

4 

항목의 형 ( 통계자료 =0, 직접 =_1 ， 

간접 =_2, 등록부 =500) 


총 

16 

내 부마디 에 대 하여 (6) 8byte 
잎마디 에 대 하여 (22) 24byte 
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6 (6) 8 바이트 


잎마디구조 아래 의 표에 서 보여 준바와 같이 ReiserFS 는 나무의 한개 마디이 며 항나 
리 머리부를 기억하는 디스크블로크에 대하여 해석해 보겠다. 

항목에 는 통계 자료항목，등록부항목，간접항목，직 접항목이 있는데 이 경 우에 는 
석에 속한다. 

Block_Head IHead IHead … IHead Poiuter 빈 공간 Item … Item Item 
0 1 NO N 10 

이제 디스크블로크의 block_head 로부터 시작하여 개별적객체를 걸쳐 다시 겨 


마당이름 

형 

크기 (byte) 

설 명 

blkjevel 

unsigned short 

2 

나무의 블로크준위 (1 一 잎 ; 2, 3, 

4 …내부) 

blk_m_item 

unsigned short 

2 

내 부블로크의 열쇠번호 혹은 잎 
블로크의 항목수 

blk 一 free_space 

unsigned short 

2 

나이 트로 된 블로크빈 공간 

blk_right_delim_key 

struct key 

16 

해 당 블로크의 오른쪽 뿌리열쇠 


총 

22 

(22) 24 잎마디 에 대 한 바이 트수 


매개 항목머 리부는 항목의 항목나무안에서 정착위치를 찾고 사용된 공간뿐아니 라 






u.ih_free_space 

ih_item_len 

ih_item_location 

ih_reseved 

_ul6 

_ul6 

_ul6 

_ul6 

2 

2 

2 

2 

간접 항목을 위 한 마지막양식화되지 않은 
마디의 빈 공간，직접항목에 대해서는 
OxFFFF, 통계자료에 대해서는 OxFFFF, 등 
록부항목의 등록부입 구점 수 
항목본체의 총 크기 
블로크안의 항목본체 에 대한 변위 
ReiserFSck 에 의 하여 리 용된 다. 


총 

24 

24byte 

sd_mode 

_ul6 

2 

파일형，허용 

sd_nlink 

_ul6 

2 

고정련결수 

sd_uid 

_ul6 

2 

소유자 id 

sd_gid 

_ul6 

2 

그룹 id 

sd_size 

_u32 

4 

파일 크기 

sd_atime 

_u32 

4 

마지 막접 근시 간 

sd_mtime 

_u32 

4 

파일의 마지막변경시간 

sd_ctime 

_u32 

4 

색 인 마디 (통계 자료)의 마지 막변경 시 간 
(sd_atime 과 sd_mtime 의 변화를 제외하고) 

sd_rdev 

_u32 

4 

장치 

sd_first 一 direct 一 byte 

_u32 

4 

파일의 시작으로부터 파일의 직접항목의 
첫 바이트까지의 변위(一 1) 

작은 파일용(파일이 직접항목만 가진다.)의 등 
록부에 대하여 (>1)，큰 파일용(파일이 간접항 
목과 직접항목을 가진다.)에 대하여(一1)，큰 
파일(파일이 간접항목은 가지지만 직접항목을 
가지지 않는다.) 






작은 파일 들은 한개 의 지 적자에 의하여 주소화되기 때문에 직접항목 (direct item) 이라 
고 한다. 


* * * 작은 파일본체 * * * 

보다 큰 파일(한개이상의 블로크디스크가 필요한)들에는 모든 련속된 블로크들을 찾 
기 위 하여 간접 항목 (indirect item) 이 라고 부르는 기 교적 인 여 러 개 지 적 자가 필 요하다. 

unfpointerO unfpointerl unfpointer2 • • • unfpointerN 

좀 더 구체 적 으로 설 명 하면 unfpointerl 큰 파일 의 본체 를 포함하는 양식 화되 지 않 
은 블로크에 대 한 지적 자 (32bit) 를 포함한다. 

다음 표에서 지적자가 양식화되지 않은 블로크를 어떻게 찾는가를 알수 있다. 


마당이름 

형 

크기 (바이 트) 

설 명 

deh_offset 

_u32 

4 

등록부입구점열쇠의 세번째 성분(이 
값에 의 하여 모든 ReiserFS_de_head 가 
정렬된다.) 

deh_dir_id 

_u32 

4 

객체의 상위등록부의 object_id 등록부 
입 구점 에 의하여 참조된 다. 

deh_object 

_u32 

4 

등록부입 구점 에 의하여 참조되 는 객 
체 의 object_id 

deh_location 

_ul6 

2 

전체 항목안의 이름의 변위 

deh_state 

_ul6 

2 

1) 입구점은 통계자료를 포함한다. 

2) 입구점은 완페된다. 


총 

16 

16byte 


여 기서 파일 이 름은 파일의 이 름을 의 미한다(리 용가능한 길 이의 바이 트배렬). 파일 이 름 
의 최 대 길 이 =블로크크기 一 64(4KB 의 블로크크기 에 관하여 최 대 이 름길 이 는 4032byte 이 다.) 

파일배치최량화에 나무의 리용 

4개 준위 파일 배치 (Layout) 최량화가 수행된다. 

▼ 론리적 블로크디스크상의 물리적위 치 에로의 넘기기 

• 론리적블로크번호에 대한 마디의 지적 

• 나무에서 객체들의 순서화 

▲ 객체가 묶어 지는 마디를 통한 객체의 균형화 
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물리적배치 (Physical Layout) 


디스크상에 서 론리적 블로크번호의 물리적 위 치 에 로의 넘 기 기는 SCSI 용디스크구동기 
제 조자들과 IDE 용장치구동기 에 의하여 실 현된 다. 물론 앞의 장들에 서 고찰한 LVM 과 같 
은 보다 높은 준위의 프로그람도 있을수 있는데 이런 프로그람普은 넘기기를 더 높은 수 
준에서 추상화한다. 구동기제작자들에 의한 론리적 블로크번호의 물리적위 치 에 로의 넘 기 
기는 보통 실 린더 (cylinder) 에 의 하여 진행된다. ReiserFS 개 발자들은 실 린더 경계를 추적 하 
지 않고도 의미론적으로 린접한 론리마디들의 거리최소화를 실제 실린더경계에 따라 근 
사적 으로 실현할수 있었다. 이 리하여 보다 좋은 체계를 실현할수 있게 되 였다. 

마디배치 (Node Layout) 

ReiserFS 는 디스크에 나무의 마디들을 배치할 때 블로크번호에 리용된 비트매프에서 
첫번째 자유블로크를 찾는다. 이 때 나무의 순서 화에 서 왼쪽린접마디 의 위 치 로부터 시 작 
하여 마지막으로 옮겨 진 방향으로 이동시 킨다. 

실험 에 의 하면 이 방법 이 다음의 성 능평 가 (benchmark) 선택 법 보다 더 효과적 이 라는것 
을 보여 주었다. 

1. 비트매프에서 첫번째 령 아닌 입구점을 취한다. 

2. 마지 막으로 옮겨 진 방향을 지 적하는 입 구점뒤 의 입 구점 을 취 한다(이 방법 은 쓰 
기속도는 3%정도 높지만 련속읽기에서는 10-20%정도 낮아 진다.). 

3. 왼쪽린접 에 서 출발하여 오른쪽린접방향으로 옮긴다. 옮겨 진 항목들이 디 스크를 
새 로운 접 수마디(보존목록을 보기 바란다.)에 도달시 키 기전에 전송마디 의 반복쓰 
기를 피할 목적으로 블로크번호를 변경시킬 때 여기에 리용된 성능평가기준은 설사 
왼쪽린접을 결정하는데서 적지 않은 휴지시 간이 추가된다 해도 마디의 현행블로크 
번호보다도 오히려 왼쪽근방으로부터 찾기를 시작할 때보다 대략 10%정도 더 빨랐 
다(현재 실현수법은 왼쪽근방의 상위객체를 읽을 때 I/O 에 위험을 조성한다.). 

ReiserFS 는 디스크구동기의 끝에 도달할 때 방향을 바꿔 주는데도 리 용된 다. 개 발자 
들은 파일에 블로크들을 배정할 때 그것이 움직이는 위치에 차이가 있는지 없는지를 알 
기 위하여 검 사를 진행 하였으며 블로크번호가 증가하는 방향으로 배정할 때 항상 현저한 
차이 가 생 긴다는것 을 알게 되 였다. 이 것은 블로크번호의 증가에 대 한 배정조작에 의하여 
디 스크회 전위 치 를 정 합시 킨데 기 인될수도 있 다. 

선행가동일지 기록 (write-ahead logging) 

대다수의 메타자료조작들은 한개이상의 블로크를 포괄하며 메타자료는 보통 한개 조 
작에 포함된 일부 블로크들만이 갱신되면 손상되게 된다. 선형 가동일지기록을 리용하면 
블로크들은 실지위 치 에 일 치되기 전에 가동일지 에 기 록된다. 폭주후에 가동일지 는 파일체 



계 를 정 상상태 로 회 복시 키 기 위하여 재 생 ( replay ) 된 다. 이 재 생 조작은 f sc k 로 하는것 보다 
훨씬 빠르며 그 시 간은 파일 체 계 의 크기 보다 가동일지 구역 의 크기 에 의하여 한정 된 다. 

ReiserFS 실행기록특성 

실행기록은 몇가지 종류의 가동일지조작과 그것의 잠금을 위한 직렬화를 요구한다. 
이 리유는 실행기록된 파일체계가 필수적으로 가동일지에 기록되지 않은 복제본보다 속 
도가 뜨다는데 있다. 따라서 실행기록은 그러한 가동일지등록부동작과 직렬화를 수행하 
기 위한 몇가지 종류의 기본적 인 조작을 요구하게 된다. 

ReisserFS 에 어떤 조작들이 있는가를 보자. 

거래 (transactions) 

실행기록방식에서 매개 조작은 서술블로크를 포함하며 그뒤에 많은 자료블로크와 결 
속블로크 (commit block ) 를 포함한다. 서술블로크와 결속블로크는 매개 론리적블로크에 해 
당한 실지디스크위치로 구성되는 순서목록을 포함한다. 가동일지는 갱신되는 순서로 보 
존되 여 야 하며 만일 쓰기프로그람이 블로크 A , B , C , D 를 가동일지 에 기 록하고 다시 A 
를 기 록하면 B , C , D , A 순서 로 가동일 지 에 순서화된 다. 블로크가 결 속되 지 않은 트랜 
잭션에 있을 때 그 블로크는 지워 져 있어야 하며 적어도 하나의 참조계수값을 가지고 
있어야 한다. 일단 한개의 거래가 디스크상에 모든 가동일지블로크들을 가지고 있기만 
해 도 실 제 완충기 들은 낡아 지 게 되 여 개 방된 다. 

목음식거래 

다중거 래 들은 단일한 원자적단위 로 결 합할수 있다. 만일 거 래 한개 가 블로크 A , B , 
C 를 가동일지에 기록하고 거래 두개가 블로크 A , C , D 를 기록하면 련결된 결과 거래 
는 서 술블로크를 쓰고 다음 블로크 B , A , C , D 를 쓰며 그 다음 결속블로크를 쓴다. 이 
조작은 좀 더 많은 전체 블로크들이 가동일지에 기록되게 할수 있지만 파일체계가 폭 
주되여 동작하지 않고 변화되는 경우가 많아 질수 있다. 거래가 언제 어떻게 서로 묶 
음화되 는가를 조종하기 위한 많은 이 행파라메터 들이 있다. 이 제 그 이 행부분에 대 하 
여 구체적으로 보자. 

비동기결속 비동기결속은 묶음식거래의 확장이다. 거 래는 디스크에 대 하여 모든 가동 
일 지블로크들을 소거함이 없 이 완료되 게 할수 있 다. 이 조작은 좀 복잡하지 만 보다 빨리 
귀환되게 하며 블로크들이 유지하고 있는 임의의 잠금을 개방할수 있게 한다. bdflush 는 
디 스크에 대 하여 변경 된 비 동기적 가동일지블로크를 자연스럽 게 해 결 한다. 

새 블로크는 케쉬 에서 제거할수 있다. 만일 블로크가 배정 되 고 디스크에 기록되 기전이 
나 가동일지에 기록되기전에 비워 지며 다음 그 거래가 완성되기전에 비워 지면 블로크는 
절대로 가동일지에 등록될수 없거나 혹은 실제디스크에 기록될수 없다. 이 현상은 많은 파 
일체 계 들에 고유하지 만 ReiserFS 에서 옳게 리 해 하자면 좀 더 연구해 야 한다. 

선택 적 인 소거기 능 이 조작은 실제 적 으로 특성보다 요구가 더 많다. 많은 블로크들 
(비 트매 프，상위블로크)은 몇번이 나 다시 가동일지 들에 등록될수 있다. 블로크가 결속되 
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지 않은 거래에 있을 때는 낡아 질수 있으며 디스크에 전송될수 있다. 그러나 가동일지 
구역이 재사용가능하면 거기에 포함된 임의의 거래는 실제위치에 소거된 모든 블로크들 
을 가지고 있어 야 한다. 

다중으로 가동일지에 등록된 블로크가 어떤 방법으로든지 소거될수 있다고 할지라도 
그 블로크는 다른 모든 블로크와의 관계에서 더 변경된 거래로 변화되며 폭주후에 메타 
자료가 손상될수 있다. 차후 거래로 될수 있는 블로크들을 소거할 대신에 거래의 가동일 
지를 디스크에 강하게 요구한다. 

폭주후에 모든 요소들이 일관화될수 있게 가동일지가 재생된다. 이것은 자주 가동일지 
에 기록되는 블로크들은 오직 한번만 매 거래당 가동일지에 등록되여야 하며 파일체계의 
올려 태우기 해제 에 관하여 블로크들의 실지위 치 에 한번만 기록되 여 야 한다는것을 의미 한다. 

자료 M 로크가동일지기록 (Data Block logging) 지 금 블로크들은 직 접항목부분이 간접 
항목에 일 치 시 킬수 있다는 사실을 초월 하여 직 접항목을 포함하는 파일의 mrnap 우에서 확 
장될 때 진행된다. 때로는 변환이 변경된 자료에 대하여 진행되기때문에 폭주후에 자료 
가 잃어 지지 않았는가를 확인하여야 한다. 

문제 는 블로크가 일 단 가동일지 에 있기 만 하면 폭주후에 블로크들을 중복쓰기할 가 
동일 지의 재 생 기 회 가 있는 동안은 가동일 지등록을 계 속해 야 한다는데 있다. 그리하여 
mark _ buffer _ dirty 가 호출되는 일은 없게 되며 대 신 져널의 호출은 블로크가 현재 거래 에 
있거나 혹은 재생될수있는 거래일 때만 블로크의 가동일지기록목적으로 존재하게 된다. 
이것은 가능한 꼬리 들을 리용하여 평 균적 인 크기 로 파일들을 일 치시 킨다는것을 말한다. 
왜 냐하면 많은 자료블로크들이 가동일지 에 기 록될 것 이 기 때 문이 다. 

파일닫기상태 에 서 묶음파일 을 실 현 하는 방법 과 가능한 꼬리 들을 리 용하지 않고 올려 
태우기를 실현하는 해결안도 있다. ReiserFS 개발그룹은 대체로 이런 문제점에 대하여 고 
찰했 을것 이 다. 

전환 (Timing) 가동일 지구역 의 크기 는 성 능에 서 제 일 큰 영 향을 준다. 이 구역 을 너 
무 작게 하면 너무 자주 그것의 실제위치에 대한 블로크의 flush 가 진행되여야 한다. 너 
무 크게 하면 재생시간이 지내 오래 걸리게 된다. 

그렇다면 정확한 크기를 어떻게 찾아 낼수 있는가? betal 에서 성능평가기준을 될수 
록 빨리 엄을수 있는 정도까지 시험해 보아야 한다. Bate 2 는 실지블로크들을 flush 할 때 
올려태 우기 선택 에 정 보적인 명 령 문들을 추가할수 있다. 이 방법 들은 보다 더 쉽 게 전환 
될수 있어야 한다. 변경된 객체들을 어떻게 얻을수 있겠는가와 관련된 최대거래크기，최 
대 묶음크기 (betch size ), 여 러 가지 시 간제 한들도 역시 중요하다. 

드롬 (ReiserFS Drops) 매개 드롭이 개별적인 열쇠를 가지는 드롭들로 한개 파일 
이나 등록부를 분할하는 문제를 고찰한다. 여기서 한개 드롭으로 압축하지 않고 갈은 
마디 를 차지하는 파일 이 나 등록부로부터 분할되 는 두개 의 드롭은 존재하지 않는다. 
매개 드롭의 열쇠객체 에 대 한 열쇠와 거기에 객체안의 드롭의 변위를 더한것 이 다. 등 
록부에서 이 변위 는 사전적의미 를 가지 며 수자적 이 며 바이트로 된 파일에 관하여 파 
일이 름에 의거한다. 몇 가지 파일체 계판본과정 에 액 체，고체，공기 방울을 가지 고 실험 
을 진행 하였으며 실현하였다. 고체덩 이는 옮겨 질수 없고 그 방울은 양식화된 마디의 
전체를 차지할 때 굳어 지기만 한다. 액체방울은 마디를 완전하게 늘무는 임의의 액 
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체방울이 마디의 공간을 차지하는 방법으로 옮겨 지게 된다. 물리적액체와 마찬가지 
로 액체 방울은 옮길수는 있지만 압축할수 없다. 공기 방울은 순전히 나무의 균형화조 
건에 맞는다. 

ReiserFS 02는 파일전체 에 대 하여서 는 액 체 방울을 실현했지 만 파일의 꼬리 에 대 하여 
서는 그렇게 하지 않았다. 파일이 적어도 크기상으로 한개 마디이면 마디의 시작점으로 
파일 의 시 작점 을 파일 의 블로크정 돈으로 맞출수 있을것 이 다. 다중드롭파일 의 시 작점 에 
대한 이러한 블로크정돈은 공간을 랑비하는 설계오유였다. 만일 기준위치가 의미론적으 
로 린접한 파일부분을 읽 을수 없을 정 도로 불투명하면 그리 고 마디 들이 서 로 가까우면 
여 유블로크를 읽 는 비 용은 파일 의 첫 마디 에 도달하기 위한 찾기 와 회 전 비 용에 의하여 
철저하게 작아 지게 될것 이 다. 비 용은 4-20 K 의 파일들에 해 당한 일정한 공간으로 되지만 
결 과적 으로 블로크정 돈에는 아주 적 은 시 간이 소비 된 다. 

다중드롭파일 의 블로크정 돈을 포함하는 ReiserFS 와 비 간접 항목들은 13 K 의 크기 로 평 
균화된 파일에 관하여 88%공간효률만을 초래한 흥미 있는 동작을 실험적으로 엄게 되 였 
다. 4 K 보다 더 큰 파일 꼬리 가 순서화된 나무에 서 4 K 보다 더 큰 다른 파일 보다 앞에 놓 
이면 드롭이 먼저 굳어 지고 정돈되며 후에 굳어 지고 정돈되기때문에 꼬리가 있는 크기 
라고 할지라도 그것은 전체 마디에 배치된다. 

현재 일부 판본에 서는 큰 파일 들의 꼬리 부분을 양식 화되 지 않는 옹근마디 들에 예 약 
된 나무준위 로 배 치 하고 양식 화되 지 않는 마디 들을 지 적하는 양식 화된 마디 의 간접항목 
들을 생 성한다. 이 내 용은 자료기 지항목에 서 하나의 연구방법 으로 알려 져 있다. 나무에 
첨 가된 이 여 유준위 는 더 적 게 균형화된 나무(지 적 된 양식 화되 지 않는 마디 들을 나무의 
부분으로 고찰한다.)를 생성하는 어용으로 되며 그것 에 의하여 나무의 최 대깊 이를 증가 
시키는 어용으로 된다. 

중간크기 의 파일 에 대 하여 간접항목을 리용하면 그 항목들을 가진 자료의 혼합에 의 
하여 지 적 자의 캐 쉬비 용을 증가시키 게 된 다. 전개 의 축소는 흔히 읽 기알고리 듬이 어 떤 
시 각에 한마디 만을 불러 내 는 결과를 초래한다. 왜 냐하면 파일자료를 가지 고 있는 마디 
를 읽 기 전에 캐 쉬 에 기 억되지 않은 간접항목을 읽 으러 고 대 기 하기때 문이 다. 

마디 에서 꼬리 와 간접항목의 혼합에 의하여 전개 가 줄어 드는 직접 적 인 결과로서 내 
부마디의 리용보다 간접항목의 리용에 의거하여 읽기를 진행하는 매 파일당 여러개의 선 
조가 있다. 가장 치명적인 결함은 파일의 읽기에 필요한 여러개 마디들의 이러한 읽기가 
드롭들에 비교될 정도의 추가적 인 찾기와 회전을 요구한다는것 이 다. 

초기드롭을 연구한데 의하면 드롭들은 보통 디스크의 배치설계나 심지어 꼬리까 
지 도 순차적이 며 내 부마디 의 선조들은 그 선조나 캐 쉬 에 있는 다른 내부마디 에 포함 
되 여 있는 모든것들이 한번에 하나의 순차적읽기 로 요청될수 있는 방법 으로 그것들을 
지 적 한다. 

마디의 비순서화된 읽기는 순서화된 읽기보다 비용이 더 들며 이와 같은 단순한 고 
찰은 효과적인 읽기최량화를 요구한다. 양식화되지 않은 마디들은 파일체계의 회복을 더 
빨리 그리고 적은 로바스트성으로 하게 하며 이때 파일체 계는 복구된 나무에 그것을 삽 
입 할 대 신 그것들의 간접항목을 읽 으며 한편 그 내 용이 파일로부터 생성된다는것 을 확신 
할수 없다. 이 방법 들은 ReiserFS 를 가동일지등록이 없는 색 인마디기 초파일체 계 와 류사하 
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게 만들어 준다. 현대적 이며 보다 개선된 해결방안은 BLOB 를 도입하는것보다도 마디의 
시 작점 에 다중마디 파일 의 시 작점 을 배 치 하기 위 한 요구를 취 소하는것 이 다. 또한 이 해 결 
방안은 고체덩이들을 이동시키는 알고리듬을 리용하여 빈번히 이동하지 않는 파일의 
80%를 묶어 주기 위한 파일체 계소거프로그람을 리용하는것 이 다. 이 방법 은 여 전히 
_ ap () 의 목적 에 효과가 적 은 양식화된 마디 들에 대 하여 서 는 문제 로 남아 있 다(이 방법 
은 페 지 표입 구점 들을 단순하게 변경 시키 는것 보다는 오히 려 쓰기전에 그것 을 복사해 야 하 
며 기 억대역근 CPU 의 어용이 나가자고 해도 어용상 비싸 진다.). 

이 리유에 대 하여 다음 판본을 위 한 계 획을 가지 고 설명한다. 이제 3개의 나무를 도 
입하겠다. 한 나무는 열쇠를 양식화되지 않은 마디들에 넘기며 다른 나무는 열쇠를 양식 
화된 나무에 넘긴다. 또 다른 나무는 열쇠를 등록부입구점들과 통계자료로 넘긴다. 

이 방법 은 파일，등록부입 구점 의 첫번째 접 근，통계 자료，양식 화되 지 않은 마디 그리 
고 꼬리 부분을 읽 기 위하여 처 음에 한 나무를 찾아 가고 다음에 다른 나무를 찾아 가는 
방법으로 디스크량단사이거 리를 길게 뛰여 넘어 야 하는것처 럼 생각할수 있다. 이때 계획 
은 다음의 알고리 듬에 따라 세개 나무의 마디 들을 끼 워 넣 는것 이 다. 블로크번호들은 마 
디가 생성되거나 혹은 보존될 때 마디에 대하여 지적되며 어떤 때는 소거프로그람이 실 
행될 때 지적될수 있다. 블로크번호의 선택은 첫째로 가깝게 배치되여야 할 다른 마디가 
어 느것 인 가에 기 초하며 다음으로 승강기 의 현 행방향에 서 제 일 가까운 자유블로크를 찾는 
데 기 초한다. 현재 우리 는 가까이 배 치 되 여 야 할 마디 로서 나무의 왼쪽근방마디 를 리용 
한다. 새 로운 도식 은 먼저 가까이 배 치 되 여 있는 마디 를 결정하며 다음으로 그 점 에서부 
터 자유블로크에 대한 탐색을 시작하는데 어느 마디를 가깝게 배 치하는가에는 보다 복잡 
한 결 정 방법 을 리용한다. 

이 새로운 방법은 동일한 묶음위 치로부터 모든 마디들이 서로 가까와 지게 하며 모 
든 등록부입구점들과 통계자료들이 그 묶음위치에 서로 그룹화되도록 하며 갈은 묶음적 
위 치 로부터 양식화된 마디 와 양식 화되 지 않은 마디 를 끼 워 넣 게 한다. 가상코드가 이 것 
을 서술하는데서는 제일 좋다. 

코드복잡성 이제 코드길이설정에서 의의가 있는 몇가지 설계방법들에 대하여 언급하 
겠 다. 보다 단단한 마디 들을 묶을수 있게 항목의 일 부만을 옮기 는 균형알고리 듬을 작성 
하면 코드의 복잡성 을 피할수 없 다. 다른 중복적 이고 결정 적 인 코드균형 화의 복잡성 은 
항목형 들의 개 수였 다. 2중화된 간접항목의 도입 과 액 체방울으로부터 공기 방울에 로의 등 
록부항목의 변화도 역 시 복잡성 을 증대시 켰 다. 파일 의 직 접 혹은 간접항목에 통계 자료를 
기 억 시 키 는것 은 통계 자료를 그것 의 자체 항목형 으로 만들었 을 때 보다도 항목들을 처 리 하 
기 위한 코드는 복잡해 졌다. NXN 코드화복잡성문제 를 가지 고 론할 때 이것은 보통 추 
상화계 층을 한개 더 보충할것 을 요구한다. 균형화된 코드복잡성 에 관하여 항목수의 NX 
N 효과는 그 설계원리 에 대 한 하나의 실례이 며 우리 는 그것 을 다음의 기 본재쓰기 에 서 주 
소화하게 된다. 

균형코드는 모든 항목의 형을 다 지원하는 항목조작모임을 리용한다. 다음 균형코드 
는 항목정 의 형 연산조종자 ( item_specific item operation handler ) 를 결 정 하기 보다 항목의 형 에 
대 한 그 어떤 여 러개의 의미를 리해할 필요가 없이 이 조작들을 호출하게 된다. 새 로운 
항목의 형 (례 를 들어 압축항목)을 추가하는것 은 현재 수행 되 는 균형코드의 많은 부분을 
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변경시킬것을 요구하기보다는 오히려 단순하게 그 항목에 관한 항목조작모임을 서술하게 
할것 이 다. 

이제 균형조작을 수행하기 위하여 어떤 원천들이 요구되는가를 결정하는 함수 
fix _ nodes () 를 어 떤 방법 으로 쓰든지 편 리하므로 균형조작시 어 떤 조작이 수행 되 는가를 
결정하는데 이 함수를 리용할것 이 다. 한가지 방법 즉 잠금이 된 마디 를 가지 고 균형 동 
작을 수행하는 함수 do _ balance () 가 복잡성 을 없 앨 수 있 다. 

Unux 핵심부에서 ReiserFS 의 설치와 배치구성 

ReiserFS 는 설 치 하기 아주 쉽 다. Linux Kernel 2.4.3 으로부터 토발즈는 표준 Linux 원천 
에 ReiserFS 를 포함시켰다. 이것은 새로운 핵심부에 관하여서는 핵심부원천에 대하여 아 
무것 도 할 필 요가 없 다는것 을 의 미 한다. 이 핵 심 부는 ReiserFS 에 의 하여 콤파일 할수 있게 
준비 되 여 있 다. 변경 된 핵 심 부에 대 하여 서 는 www . name sys.com Web 싸이 트로부터 검 사 
수정 을 얻 기 위하여 리용되 는 절 차가 있 으며 그다음 표준 Linux 원 천코드에 검 사수정 을 
적용해 야 한다. 

Unux-2.2.) (핵심부 

Linux _2.2 .x 핵심부에 관하여 다음과 같은 단계를 거처야 한다. 

1. 거 울들중의 하나로부터 제 일 마지 막 ReiserFS 검 사수정 을 얻 는다. Hnux -2.2.19 - 
ReiserFS -3.5.32- patch . bz 2 을 얻으러고 하면 이것을 아무곳에나 넣 는다. 실례로 
/ usr / src /2.2.19 / 

2. http : // www . kernel.org 로부터 2.2.19 의 핵심부원천을 엄은 다음 그것을 아무곳에 
나 넣는다. 실례로 / usr / src /2.2.19/ linux . 이제 / usr / src /2.2.19/ 에서 “ Is ” 지령을 수행 
하면 다음과 갈은 결과가 나온다. 

# Is 

linuxlinux -2.2.19- ReiserFS -3.5.32- patch . bz 2 

3. ReiserFS 를 핵심부에 적용한다. 

# cd / usr / src /2.2.19 

# bzcat linux -2.2.19- ReiserFS ~3.5.32- patch . bz 2 / patch-pO 

4. Linux 핵심부를 콤파일하고 ReiserFS 지원을 설정한다. 

# cd / usr / src /2.2. 1 9 /linux 

# make improper ; make menuconfig 

5. ReiserFS 지원을 여기에 설정 한다. 실험적 특성들을 투입 하는것이 필요하나 정확한 
핵 심 부에 의 존하여 다음의 것 을 리용한다. 

# make dep ; make bzlmage 

6. 배 치 구성 시 ReiserFS support 의 질 문에 따라 y 혹은 n 으로 대 답한다. 배 치 구성 Web 
페지를 읽는다. ReiserFS 를 모둘로서 설정 하려면 다음의것 을 실행 한다. 
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# make modules 

# make modules_install 

앞으로 ReiserFS 를 갱 신할 때 모둘을 재 콤파일해 야 한다고는 생 각하지 말아야 
한다. 

리론은 좋지만 주요하게는 파일체계에 대한 대면부가 전체 시간동안에 빨리 변경되 
기때문에 현실성은 적 다. 모둘만을 재를파일하여 발생되는 오유는 완전히 숨겨 질수 
있으며 개발자들은 전체를 재를파일하지 않기때문에 그것이 어디 있는가를 알수 있 
다. 핵심부의 이메지는 / usr / src / 2.2.19/ linux / arcM 386/ boot/bzImage 이 다. 

7. ReiserFS 편의프로그람들을 콤파일 하고 설 치한다. 

# cd / usr / src /2.2. 1 9/ linux / fs / ReiserFS/utils 

# make ; make install 

8. ReiserFS 로 새로운 Linux 핵심부이메지를 적당한 위치에 복사한다(보통 “/ boot ” 등 
록부에 둔다.). 

9. / etc / lilo . conf 파일 을 변경 시 키 며 새 로운 핵 심 부로 기 동할수 있게 한다. lilo 지 령 을 
수행 하고 lilo -21.6 혹은 더 새 로운 파일 을 리용한다. 

Lilo - 21 .6 - or—newer 

10. 구축된 핵 심 부를 기 동하며 mkreserfs 로 구획 을 준비 하며 그것 을 올려 태 우기 한다. 

# mkreiserfs / dev/xxxx 

# mount / dev / xxxx / mount - point-dir 

혹은 

# mount-t reiserfs / dev / xxxx / mount - point-dir 

11. 작업 을 진행한다. 


Linux-2.4. 0~2. 4. 2 


ReiserFS 코드는 Linux 2.4.1- pre 4 의 Linux 핵심부안에 있다. 

1. Linux 2.4.2 를 얻는다. http : "切 ww . kemel.org 

2. 제 일 마지 막 ReiserFS -3.6 .x patch -1- 얻 는다. 

3. 검사수정을 적용한다. 

# zcat linux -2.4.2- reiserfs -20010327- full . patch.gz / patch-pO 

4. 핵 심부를 를파일 한다(먼저 설명한것 처 럼 실험 적특성 들을 투입한다.). 

5. 임의의 등록부에 tar 압축을 해제한다. 

6. ReiserFS 편의프로그람을 를파일 하고 설 치한다. 

# tar-xzvf reiserfsprogs - 3. x .0 i - l . tar.gz 

# cd reiserfsprogs -3 . x . Oi -1 

# ./configure 

# make ; make install 

7. 구축된 핵 심 부를 기 동하고 mkreiserfs 구획 을 준비한다. 


283 





배치구성 (C 에 figuratbn ) ReiserFS 기능성에 영향을 주는 콤파일시간선택항목이 5 
inux 핵심부의 배치구성단계를 수행할 때 이 선택항목들을 설정해 줄수 있다. 


make config 
make menuconfig 
make xconfig 

ReiserFS 선택 ( option ) 항목을 핵심부배 치구성으로 전환한다. 이 조작은 ReiserFS 의 부 
수들을 구축한다. 

ReisreFS 를 구축한다. 이 조작은 ReiserFS 를 핵 심 부방식 이 나 혹은 자립 형핵 심부방 
_로 구축한다. 


선택항목 

설 명 

CONFIG 

REISERFS 

CHECK 

핵 심 부배 치 구성 시 이 항목을 yes 로 설 정 하면 reiserFS 는 이 조작을 통* 
여 내 부일관성 의 매 개 가능한 검 사를 진행한다. 가능한 검 사를 진1 
하되 순차적 으로 천천히 진행한다. 이 선택 의 리용은 개 발그룹으로 
하여 금 말단사용자에 대 하여 그 영 향을 근심하지 말고 오유수정시 으 
일 관성 을 검 사할수 있게 한다. 만일 오유통보가 보내 기직 전에 있 다국 
yes 로 대답하며 쓸모 있는 오유통보문을 얻을수 있다. 대다수의 사정 
자들의 경우에는 no 로 대 답한다. 

CONFIG 

REIGERFS 

RAW 

이 항목을 yes 로 설정하면 등록부들을 우회하여 ReiserFS 나무에 대 t 
행대면부를 제공하는 ioctl 들의 모임을 가능하게 하며 변경된 파일들될 
자동적 으로 제거한다. 이 조작은 스무드캐 쉬 등록부를 위하여 설계된 설 
험 적 특성 이 다. Documentation / filesystems / reiserfs _ raw.txt 를 보기 바란디 
이 기 능은 ReiserFS 를 back_end squid 로 리 용하기 위 하여 특별 히 
설계 되 였다. 일 반적착상은 모든 파일체 계휴지 시 간을 피 하며 ReiserR 
내부나무를 직접 찾을수 있다는것이다. 일반적핵심부에는 없다. 

USE INODE 

GENERATION 

COUNTER 

색 인마디세대계층을 알아 내기 위 한 3.6 상위블로크의 s _ inode_generatioi 
마당을 리용한다. 정의되지 않으면 이 목적을 위하여 대역사건계수기를 e 
용한다 (exG 과 대다수의 다른 파일체계에서 하는것처럼). 색인마디세대계부 
의 동작은 NFS 에서 중요하다. 이 변수는 핵심부배 치구성수속들을 통하 
서는 리용할수 없다. include / linux / reiserfs _ fs . h 를 수동으로 편집 한다. 

REISERFS 

HANDLE 

BADBLOCKS 

비트매 프를 조종하기 위하여 ioctl 을 허 용한다. 이것은 잎량블로크크 
종을 위한 원형 으로 리용될수 있으나 실제 적 인 해 결 방법 은 지 금 폭 
행 중에 있 다. 이 변수는 핵 심 부의 배 치 구성 수속을 통하여 서 는 리용 t 
수 없 다. edit include / linux/reiserfs fs.h 름 수동으로 편집 하다. 다음 리 질 





제 1 0장. 확장파일체계 

Linux 용의 가장 전망성 있는 새 로운 실행기 록파일체 계 의 하나는 SGI 가 후원하는 
XFS 파일 체 계 이 다. XFS 파일 체 계 는 Irix 조작체 계 하에 서 처 음으로 제 안되 였 으며 2000년과 
20()1 년 에 SGI 의 내 부와 외 부의 개 발자그룹들에 의 하여 Linux 에 이 식 되 였 다. XFS 는 
Irix 5.3 조작체 계용의 비실행기 록 EFS 파일체 계 를 위한 교체판으로서 실 리콘 그라픽 스 
(Silicon Graphics ) 에 의 하여 도입 되 였 다. 

앞으로 기억장치가 더욱 확대될것과 자료에 더 빨리，더 효과적으로，보다 안전하 
게 접 근하고 봉사할수 있는 강력한 봉사기 들이 필 요할것 이 라는것 을 예 견하여 이 에 대 
한 연구사업 이 활발히 진행되 였 다. XFS 의 설계 와 개 발방향을 요약하면 다음과 같다. 

▼ 파일 체계 는 과학적 인 파일 과 콤퓨터봉사기로, 상업 적자료처리봉사기로 그리 고 수 
자식 매 체봉사기 로 리용할수 있 어 야 한다. 

• XFS 는 오유로부터 신속히 복구되여야 하며 장시간 일관성 있게 디스크에 기초한 
자료를 유지하여 응용성을 더욱 넓혀야 한다. 

• 64 bit 규모의 파일에 대한 효과적지원능력을 가져야 한다. 서로 다른 대역을 가진 
파일들이 블로크에로의 접근에서 성능상 위반이 아주 적거나 없어야 한다. 

일부 디스크공간위반(실례로 첨수들)으로 하여 성능을 더욱 높이게 한다. 대규모 
파일의 끝에 있는 블로크까지의 찾기를 파일체 계의 자료구조를 통하여 진행하는 
선형탐색방법 은 그닥 좋은것 이 못된다. 

• 예 비파일 에 대 한 효과적 지 원능력 이 있 어 야 한다. 우연적 인 구멍 ( holes ) 처 리 도 지 
원되여야 한다. 구멍은 써지지 않고 령으로 읽어 지는 파일대역을 말한다. 또한 
변경된 자료에 대한 검색과 새로운 자료의 삽입에서 표현이 디스크공간상으로나 
CPU 시 간상으로도 효과적 이 여 야 한다. 령 으로 씌 여 진 블로크(구멍 에 의 하여 교체 될 
목적으로 씌여 진)에 대하여서는 검사할 필요가 없다. 

• 1 KB 정도로 작은 파일에 대하여서도 효과적으로 지원해 야 한다. 표준뿌리 ( root ) 나 
usr 파일체계는 프로그람원천을 포함하는 파일체계와 마찬가지로 많은 파일을 가 
지 고 있 다. 대 다수의 기 호적련결 들도 역 시 이 항목에 일 치한다. 

• 대규모등록부들에 대하여 효과적인 지원기능 즉 람색，삽입，제거와 같은 기능을 
가져 야 한다. 이것은 긴 등록부를 통한 선형탐색을 피 하기 위하여 몇 가지 종류의 
첨수도식 이 필요하다는것을 말해 준다. 고장으로부터 회복시간은 파일체계의 크 
기에 따라 증가하지 않는다. 그 시간은 고장상태의 어느 한 시각에 파일체계가 
어떤 동작상태준위에 있는가에 따라 커질수 있다. 복구에서는 일관성을 확인하기 
위 하여 모든 색 인마디 와 등록부를 주사해 야 한다. 이것은 선택 하는데 따라 ( MS - 
DOS 에서와 같이 동기적성질) 일관성은 가동일지에 의하여 담보되지만 속도가 상 
당히 떠진 다는것 을 암시해 준다. 사용자에 게 성 과적 으로 귀 환된 후에 도 결 속된 
변경조작이 완료될 때까지 회복동작을 계속 진행한다. 일부 조작들은 가동일지 
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등록과 관련되는 조건에서는 최소한 동기화되여야 한다. 이것은 반드시 파일의 
생성과 소거를 포함하며 부차적인 쓰기(완충화된)는 포함하지 않는다. 

• ACL 과 다른 POSIX1003.6 을 기능적으로 지원해야 한다. 여기에는 몇가지 형태의 
위 임 접 근조종，정 보의 표식 화，듣기 등이 포함된 다. 

▲ 디 스크의 쌕 터크기 로부터 64KB 혹은 256KB 까지의 범 위 에서 다른 론리 적 블로크 
크기 를 지 원해 야 한다. 블로크의 크기 는 파일생성시 에 설정된다. 이 크기 는 파일 
체 계 에서 최소배정 단위 이 다(색 인마디 를 제 외 하고). 

최초의 개발자들은 이러한 목적을 념두에 두고 SGI 의 프로그람작성자들과 기타 연 
구자들의 방조밑 에 속도가 현저 히 빠르며 효과적 일뿐아니 라 Linux2.4.x 에 이 식 할수 있는 
완전히 확장가능한 파일체계를 도입하였다. 이 책을 쓸 때에 XFS 는 이미 변경된 2.2.1x 
와 보다 새로운 2.4.x 를 다같이 안정베타판본에서 실행되고 있었다. 판본 2.4.4 에서와 같이 
XFS 는 이미 표준 Linux 핵심부원천코드의 한부분으로 되였고 핵심부배치구성시의 선택항목 
의 하나로 되였다. 


XFS 으 I 실현 

Linux 체계의 다른 모든 파일체계와 마찬가지로 XFS 는 VFS 에 기초하여 실현되며 따 
라서 VFS 의 장에서 론의된 모든 조작들이 XFS 에도 그대로 적용된다. 

XFS 파일 체계는 실 행기록파일 체계 이 다. 이 사실 은 파일 체계 의 메 타자료에 대한 갱신 
(색 인 마디，등록부，비 트매 프 등)이 최 초의 디 스크블로크를 갱 신 하기전 에 디 스크상의 직 
결가동일지구역 에 기록된다는것 을 의 미한다. 조작이 실행되지 않거 나 혹은 재실행되는것 
과 갈은 폭주사건시 에 가동일 지 에 주어 진 자료를 리용하여 파일 체 계 를 안정한 상태 로 
회복시킬수 있다. 이와 갈은 기술적실현은 체계가 폭주될 때 능동상태의 파일체계를 올 
려태우기전에 파일체계검사 및 회복프로그람 (fsck) 을 교체시키는것이다. 

XFS 는 이 책 의 LVM 장에 서 서 술된 LVM 을 리용한다. LVM 의 웃준위 에 서 XFS 를 리 
용하려 는 독자들을 위 하여 현재 XFSCVS 나무가 (20()1 년 5월 현재 로서 의 XFS 1.0 시 험 판) 
이미 LVM beta6 코드와 몇 가지 XFS 용의 묘안들을 포함하고 있다는것을 지적 해 둔다. 
beta7 에 는 일부 론리 적 문제 점 들이 존재 하기 때 문에 현행 LVM 판본 (beta7) 대 신에 이 판본을 
계 속 쓸것 을 권고하고 있 다. XFS 파일 체 계 를 포함하는 LVM 의 속성올려태 우기 동작은 파 
일 체 계 가 실 행 기 록속성 이 므로 진 행 될 수 없 다. 

XFS 는 64bit 파일체계 이 다. 32bit 응용프로그람으로부터 64bit 파일에로의 접근을 지원하 
기 위하여 새 로운 대 면부가 64bit 의 파라메 터 를 취 할수 있게 정의되 여 야 한다. 이 대 면부 
들은 응용프로그람이 체 계 호출준위 아래 로 64bit 필 터 링 (filtering) 하는가 32bit 필 터 링 하는가에 
는 관계 없 이 명 백하게 핵 심 부에 서 지 원되 여 야 한다. 파일 체 계 와 관련한 호출은 모든 파일 
체계형태에 맞게 읽기，쓰기，열기， ioctl 등으로 실현된다. 이 조작들은 VFS 대면부를 통해 
매개 파일체계형식에 관하여 서로 다른 부분프로그람들로 벡토르화되여 있다. 32bit 와 
64bit 대 면부는 다같이 기 본 이와 장치 에 의 하여 지 원된 다. 232bit 보다 긴 파일 에 대 하여 
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고유하게 동작하는 32 bit 응용프로그람의 의 미 론적구조는 이 장의 마지 막에 서 취 급한다. 
XFS 의 기본 구성성분은 목록화되여 있다. 


▼ 가동일 지 관리 기 -디 스크공간의 개 개 의 대 역 에 대 한 모든 메 타자료변경 을 직 렬 로 
가동일지에 기록한다. 

• 캐 쉬관리기 

• 잠금관리기 -파일 체 계안의 디 스크공간배 정 을 관리한다. 

• 속성관리기 -파일 체 계 속성 조작을 관리한다. 

• 체계호출과 VFS 대면부 

▲ 이 름공간관리기 -경 로이 름을 파일 참조로 변환하는 파일 체 계이 름짓 기 조작을 실 현 
한다. 

가동일지관리기 

파일체계메타자료에 관한 모든 변경내용(색인마디，등록부，비트매프 등)은 디스크공 
간의 하나의 분리대역 에 직 렬로 가동일지 에 기록된다. 이것들이 매개 파일체계 에 관한 
개 별적 가동일지이 다. 가동일지 는 메 타자료가 디 스크에 기 록되 기전에 폭주장애 가 발생할 
때 일 관성 있 고 정 확한 파일 체 계 (회 복) 를 빨리 재 구성할수 있 게 한다. 가동일 지공간은 
안전을 위 하여 파일체계공간으로부터 독립적으로 배정된다. 가동일지관리기는 캐 쉬로부 
터 쓰기 조작순서 를 조종하는 공간관리 기 에 의하여 제 공되 는 정 보들을 리 용한다. 왜 냐하 
면 특정한 가동일 지 는 폭주가 생 길 때 정 확성 을 보장하기 위한 자료조작에 앞서 서 혹은 
차후에 순서화되여 야 하기때문이 다. 

공간과 이름관리기부분체 계는 가동일지관리기 에게 가동일지등록요청 을 보낸다. 매 
개 요청 은 가동일 지용의 특별한 가동일 지블로크라든가 혹은 다중블로크에 채 워 진 다. 
가동일 지 는 쓰기 가 마지 막끝에 도달할 때 덧 붙여 지 는 순환대 기목록으로 실 현된 다. 
매 개 가동일지입구점 에는 가동일지렬번호가 불여 져 있으므로 가동일지의 끝은 제 일 
높은 번 호를 조사하여 알아 낼수 있다. 

폭주가 발생한후 가동일지 는 파일체 계 가 리 용되 기 전에 회 복되 여 야 한다. 가동일지 에 
기록되고 완성된 조작들은 파일체계의 자료대역에는 아직 기억되지 않았기때문에 파일체 
계자료와 일관성상태를 정 확하게 반영할수 있도록 재수행된다. 여 기 에서 가동일지 관리 기 
의 역할은 가동일 지레 코드들을 식 별 하며 회 복조작을 수행 하기 위하여 파일 체 계 의 다른 
프로그람부분을 호출하는것 이 다. 가동일지 조작은 해 당 기록권의 가동일지부분에 대 하여 
보다 높은 성 능을 얻 기 위하여 블로크들로 묶어 준다. 이 블로크를 가동일 지레 코드라고 
부론다. 대 표적 으로 가동일 지레 코드들은 비동기적 으로 기 록되 며 가동일 지관리기 는 체 계 
의 보다 높은 준위 에 될수 있는 한 빨리 현행 가동일지레 코드의 쓰기 를 강하게 요구하도 
록 지 령한다. 주어 진 가동일지 의 쓰기 는 선행한 가동일지 가 완료될 때 까지 출발하지 못 
한다. 
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캐쉬관리기 

캐쉬는 기계적으로 마디국부화한 여러가지 파일체계의 디스크블로크의 캐쉬이다. 읽 
기요청은 캐쉬로부터 만족되며 쓰기요청은 캐쉬로 써질수 있다. 캐쉬입구점들은 사용빈 
도와 파일체계의 의미적구조를 고려하는 방향에서 새 입구점이 요구될 때 소거된다. 파 
일체 계메 타자료만이 아니 라 파일 자료도 캐 쉬 에 기 억된다. 사용자요청 은 기 발설정 에 의 하 
여 (0_ DIRECT ) 캐 쉬 를 쓰지 않을수도 있 다. 그렇 지 않은 경 우에 는 모든 파일 체 계 I / O 들 
이 캐쉬를 거쳐 진행된다. 

현재 완충기대 면부는 두가지 방향으로 확장되 고 있다. 첫째 로 대 면부의 64 bit 판본 
은 XFS 의 64 bit 파일크기를 지원할수 있도록 첨가된다. 둘째로 캐쉬클라이언트가 조작 
기 간에 완충기들을 수집하거 나 변화된 완충기를 가동일지관리기에게 보내며 또 성과 
적으로 가동일지등록을 수행한 다음에 모든 완충기들을 개방할수 있게 거래기술이 제 
공된다. 앞으로의 배포판들에서는 캐쉬가 파일체계에 관하여 기계와 원격으로 자료를 
보존하게 될것이다. 

잠금관리기 

잠금관리기는 잠금시간의 길이를 단축하고 보존하기 위하여 보다 개선된 알고리듬을 리 
용한다. 동시에 가동일지관리기설계에서는 파일체계의 객체들이 한개 클라스터만이 여러 마 
디안에 서 잠금될 수 있게 분산파일 체 계 조작을 준비 하고 있 다. 

공간관리기 

공간관리기는 파일체계안에서 디스크공간배정을 관리하며 한개 파일(바이트렬)을 디 
스크블로크의 렬로 넘기기할 임무를 띠고 있다. 파일체계의 내부구조 즉 배정그룹(실린 
더)，색 인마디，빈 공간관리는 공간관리 기 에 의하여 조종되며 또 넘 기기함수에 의하여서 
도 조종된다. 

설계에서 공간의 배치구조선택은 64 bit 파일이 성기여 질 가능성을 포함하여 대규모 
파일 이 나 파일체 계의 효과적지 원요구의 영향을 받는다. 공간관리기 는 또한 순차적처 리를 
진행할 때 찾기 동작을 피할수 있게 블로크의 배 치 구조를 최 량화할 임 무를 가지 고 있으며 
디스크상에서 서로 가까이 있는 련관된 파일(같은 등록부안의)들을 유지해야 할 책임이 
있 다. 

매개 파일체계는 가동일지，메 타자료，자료 및 실시간부분기록권들로 분할된다. 보통 
상태 에서 는 자료부분기록권과 실시 간 부분기 록권이 존재하지 않는다. 만일 자료부분기록 
권 이 존재하면 보통 사용자자료는 그안에 존재하며 그렇 지 않으면 메 타자료는 부분기 록 
권에 기 억된다. 실시 간파일 을 위한 자료블로크들은 실시 간부분기 록권이 존재하면 그안에 
기 억되며 그렇지 않은 경 우에 는 메 타자료부분기 록권에 기 억된다. 모든 파일체 계자료들은 
가동일 지 와 메 타자료부분기 록권 에 기 억 된 다. 
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공간관리 기 는 매 개 파일 체 계 메 타자료와 자료부분기 록권을 많은 배 정 그룹들로 분할한 
다. 부분기록권이 존재할 때 배정그룹은 메타자료와 자료부분기록권들로 구성되는 블로 
크들을 포함한다. 매개 배정그룹은 색인마디들의 모임과 자료블로크 그리고 배정을 조종 
하기 위 한 자료구조체들을 가지고 있다. 색 인마디를 포함하는 블로크들은 디스크공간을 
더 효과적 으로 리 용하기 위 하여 자료블로크들로부터 동적 으로 배정된다. 배정 그룹들을 
위한 색인마디렬의 위치에 관한 정보는 보통파일 (B 나무에 있는)에 관하여서와 같은 방법 
을 취 한다. 배 정그룹안의 자유블로크들은 하나 혹은 두가지 도식 에 의하여 계 속 유지되 
게 된 다. 첫 도식 은 비 트매 프와 출발비 트매 프블로크에 의하여 구성 되 는 계 수기 들의 모임 
그리 고 빈 범 위의 log 2 크기 를 리용한다. 두번째 도식은 B 나무의 쌍을 리용하는데 하나는 
빈 범위 의 크기 에 의하여 첨수화되 여 있고 다른 하나는 빈 범위의 출발블로크에 의하여 
첨수화되여 있다. 사용될 도식은 두개의 조작들이 시험적으로 실현되고 그것들의 성능이 
확인된후에 선택할수 있다. 실시간 부분기록권은 여러개의 고정크기의 범위들로 분할된 
다. 크기는 mkfs 실행시에 선정하는데 적어도 1 MB 정도로 클것이 예견된다. 이 크기는 2 
의 루승으로 되지 말아야 하며 반드시 다중파일체계블로크크기로 되여야 한다. 이것은 
기 록권의 배 치구성 이 나 그것 의 다중화에 서 리상적 인 I / O 크기 로 될 수 있 다. 메 타자료부분 
기 록권에서 단일범위 는 실시 간부분기 록권의 범위들을 위한 배정비트매 프를 포함하며 다 
른 범위는 매 비트매프블로크(빈 범위의 번호)당 요약정보를 포함한다. 이 가변적인 배정 
방법 은 실시 간부분기록권이 객체 로 선택되는데 그 근거 는 고정크기범위 에 의하여 배정 이 
가능하게끔 성능이 개선된데 있다. 

파일의 기억은 파일의 크기와 접근에 의존하는 세가지 방법들가운데서 어느 하나로 
표현된다. 작은 파일 에서는 파일안의 자료가 색 인마디 에 기 억된다. 중간규모의 파일 에서 
는 색 인 마디 가 파일 의 자료를 가지 고 있는 크기 에 대 한 지 적자를 포함한다. 대 규모의 파 
일 에 관하여 서 는 색 인마디 가 파일안의 론리 적 위 치 에 의하여 첨수화된 B 나무의 뿌리블로 
크를 포함하는데 뿌리블로크에 서 레 코드들은 파일자료를 포함하는 디 스크범 위 들을 지 적 
한다. 이 기 억구조는 대 규모적 으로 토막화되고 성 긴파일을 B 나무첨수관리 로 약간한 휴지 
시간을 가지고 효과적으로 실현되게 한다. 

능동파일 체 계 는 보다 많은 공간을 토대기 록권에 보충하는 방법 으로 확장할수 있 다. 
이 조작은 공간관리 기 에 의하여 직 결방식 으로 지 원되 는데 이 때 공간관리기 는 파일 체 계확 
장에 대 한 요청 을 접수하고 그것을 실현하기 위하여 디스크상의 구조와 기 억내구조를 갱 
신한다. 앞으로의 실현에서는 단일파일체 계 에서 공간관리조종을 체 계의 다중마디환경으 
로 분할하는 기 능을 지 원할것 이 요구된 다. 첫 번째 실 현에 서 는 이 기 능을 고려 하지 않은 
것이다. 

속성관리기 

속성관리기는 파일체계의 속성조작을 실현한다. 즉 이름공간에서 객체와 련관된 임 
의의 사용자정의속성에 대한 검색과 기억조작을 실현한다. 속성이란 이름과 값의 쌍을 
의 미하는데 여 기서 이 름은 인쇄 가능한 문자렬이 며 값은 임 의의 작은 바이 트렬이 다. 속성 
을 사용자응용프로그람이 나 혹은 핵심부에 의하여 조종할수 있다. 어떤 속성들은 체계 에 
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의 하여 미 리 정 의 되 며 UNIX 대 면부와 새 토운 속성 접 근체 계 호출 실례 로 파일접 근과 변경 
시간 등을 리용하여 접근할수 있다. 

속성 은 참조되 는 객 체 의 색 인마디 에 첨 가하는 방법 으로 내 부적 으로 기 억 되 나 속성 관 
리기는 색인마디와 련관된 속성구조체를 관리한다. 그러나 파일의 허가권과 시간표식과 
같은 이 름공간관리 기 에 의하여 조종되 는 마당들은 관리하지 않는다. 

객체가 생성될 때 배정되는 임의의 속성은 하나도 없으며 존재하는 임의의 속성은 
객체가 파괴될 때 역시 파괴된다. 속성은 색인마디들사이에 서로 공유되지 않는다. 

접 근조종목록들은 색 인마디 들사이 에 서 속성 이 공유되 는것 과 갈은 특별한 경 우로서 
조종된다. 이 것은 임 의의 속성 이 나 혹은 속성값을 가진 파일체 계 의 모든 객 체 들을 빨리 
찾을수 있 다는것 을 의 미한다. 일부 응용체 계프로그람들은 속성 에 대 하여 알아 내 기 위하 
여 변경될수도 있는데 례를 들어 cp 는 파일을 복사할 때 선택된 속성들도 복사한다. 체 
계 여 벌복사편의 프로그람은 객체를 여 벌복사하거 나 회 복할 때 객체의 속성도 여 벌복사하 
고 회복한다. 표준 NFS 는 전통적 인 UNIX 모임을 초월하여 속성들을 지원하지 않는다. 
따라서 이 속성들은 표준 NFS 를 통하여 XFS 파일체계로 접근하는 클라이언트에 대하여 
서는 어떤 방법으로도 볼수 없다. 

이름공간관리기 

이 름공간관리기 는 파일 체 계 의 이 름짓 기조작들을 실 현 하며 경 로이 름을 파일참조로 변 
환한다. 파일은 내부적 으로 파일체 계 와 색 인마디번호에 의하여 식 별된다. 색 인마디 는 파 
일 에 관한 정 보를 유지 하는 디 스크상의 구조체 이다. 색 인마디번호는 특정한 파일체 계안 
의 색 인마디 의 표식 (혹은 첨 수) 이 다. 파일 은 또한 파일 유일 id 라고 부르는 파일 에 관한 
유일한 수치 적값에 의하여 식 별된다. 파일 체 계 는 “magic cookie ” ， 대 표적 으로 뿌리색 
인마디의 기억주소라든가 혹은 파일체계유일 id 에 의하여 식별된다. 파일체계유일 id 는 파 
일체계 가 생성 될 때 그리 고 파일체 계 가 소거 될 때 까지 그 파일체 계 와 유일적 으로 련관될 
때 지 적된다. 보충적 인 림 시 적유일 id 즉 파일체 계 I/O 유일 id 는 파일체 계 가 올려태 우기 될 
때 마다 생성 되 며 올려태 우기기 간에 만 유효하다. 

이 름공간관리기 는 등록부구조체 와 파일허 가권 이 나 시 간표식 과 갈은 공간관리 에 관 
련없는 색인마디의 내용을 관리한다. NFS 를 비롯하여 다른 파일체계로부터 제기되는 
요청은 이름공간관리기가 색인마디를 찾는데 리용하는 파일핸들을 가진 체계에 도달한 
다. 이 파일핸들은 파일 체 계 나 색 인마디 를 추론하는데 충분한 정 보를 가지 고 있 으며 
파일체 계 의 판본도 표시한다. 분산 XFS 파일체 계 에서 다른 마디들로부터 오는 요청 은 
파일체 계의 유일 id 나 색 인마디번호, 파일유일 id 로 들어 갈수 있으며 이 시 점 에서 두가 
지 식 별형 이 맞는다는것 을 립 증할수 있다. 이 름공간관리기 는 이 름짓 기조작을 고속으로 
진행 하기 위하여 캐 쉬 를 리용할수도 있다. 이 름변환과 관련 한 구체 적내 용은 호출자로 
부터 숨겨 져 있다. 

현재 이 름공간관리기 의 올려태 우기의 미 론의 설계 에 는 올려태 우기점 이 라고 부르는 
파일체 계마디 가 있는데 이 올려태 우기점 은 현행파일체 계 의 빈등록부올려태 우기점 을 교 
체 하는데 리용된다. 올려태우기점 마디는 파일체계 유일 id 를 포함한다. 이름짓기 조작기 
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간에 원격 파일 체 계 를 참조하는 올려 태 우기 점 을 만나게 되 면 통보문이 이 름짓 기 요청 에 
따라 조작을 완성하기 위하여 그 파일체계 id 를 가진 파일체계를 관리하는 원격기계에 
전송된다. 

선택적이며 확장성 있는 이 름짓기도식 은 통보문대기 렬의 다른 한끝에 존재하는 실체 
를 프로그람화함으로써 사용자방식으로 실현될수 있다. 이 방식은 체계의 첫번째 발표에 
서는 실현되지 않은 내용이다. 

XFS 파일체계의 관리 

XFS 관리 는 기 록권과 파일 체 계 를 생 성하거 나 유지 하는데 필 요한 편의프로그람들을 
포함한다. 또한 기록권조종，파일체계조종，올려태우기，올려태우기해제，여벌복사，회 
복，계 층적파일 체 계 등을 위한 프로그람적 인 대 면부를 포함한다. 앞으로 관리 지 원기 능은 
기 록권과 파일 체 계 의 올려태 우기 , 여 벌복사 기 타 기 능에 대 한 원격접 근을 가능하게 할수 
있도록 확장될것이다. 그라픽스대면부들은 필요한 새로운 도구 즉 기록권관리를 위한 
MSD 의 체 계관리그룹에 의하여 제 공될 것 이 다. 

XFS 구조체와 조작 

이 절에서는 XFS 의 핵 심 안의 색 인마디의 생성，관리，소거 에 대 하여 서술한다. 

색인마디의 자료구조체 

XFS 의 핵 심안의 색 인마디구조체 는 다음과 같이 정 의 된다. 
typedef struct xfs_inode { 

struct xfs_ihash *i_hash; /* pointer to hash header */ 
struct xfs_inode *i_next; /* inode hash link forw */ 
struct xfs_inode **i_prevp; /* ptr to prev i_next */ 
struct xfs_mount *i_mount; /* fs mount struct ptr */ 
struct xfs_inode *i_mnext; /* next inode in mount 1 s list */ 
struct xfs_inode **i_mprevp; /* ptr to prev i_mnext */ 
struct vnode *i_vnode; /* ptr to associated vnode */ 
dev_t i_dev; /* dev containing this inode */ 
xfs_ino_t i_ino; /* inode number (agno/agino) */ 
xfs_agb 1 ock_t i_bno; /* ag block # of inode */ 
int i_index ; /* which inode in block */ 
xfs_trans_t *i_transp; /*ptr to owning transaction */ 
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xfs_inode_log_item_t i_item; /* logging information */ 
mrlook_t i_lock; /* inode lock */ 
sema_t i_flock; /* inode flush lock */ 

unsigned int i_pincount; /* # of times inode is pinned */ 

sema_t i_pinsema; /* inode pin sema */ 

ushort i_f lags; /* mi sc state * / 

ulong i_vcode; /* version code token (RFS) */ 

ulong i_mapcnt; /* count of mapped pages */ 

ulong i_update_core; /* inode timestamp ditry flag */ 

size_t i_bytes; /* bytes in i_ul */ 

union {xfs_bmbt_rec_t *iu_extents; /* linear map of file extents */ 
char * iu_data; /* inline file data */} 

i_ul; xfs_btree_block_t *i_broot; /* file’s in-core b-tree root */ 

size_t i_broot_bytes; /* bytes allocated for root */ 

union {xfs_bmbt_rec_t iu_inline_ext [2]; /* very small file extents */ 

char iu_inline_data [32] ; /* very small file data */ 

dev_t iu_rdev; /*dev number if special */ 

xfs_unid_t iu_unid; /* mount point value */ } 

i_u2; ushort i_abytes; /* bytes in i_u3 */ 

union {xfs_bmbt_rec_t *iu_aextents; /* map of atribute extents */ 
char*iu_adata; /* inline atribute data */} 

i_u3; xs_dinode_core_t i_d; /* most of the on-disk inode */} 
xf s_inode_t; 

색인마디의 생명주기 

이제 우리는 디스크를 읽는 시각부터 핵심안의 색인마디구조체가 핵심부의 히프 
( heap ) 에 귀 환되 는 시 간까지 의 핵 심안의 색 인마디 생 명 주기 를 고찰한다. 

1 단계(핵심안의 색인마디배정 ) 

우선 핵심 안 색인마디사용자는 xfs _ iget () 혹은 xfs _ trans _ iget () 을 호출하여 색인마디 
를 취 하도록 한다. 호출자는 요구되 는 색 인마디의 색 인마디번호를 정 의하며 색 인마디 
가 독점방식 으로 잠금되 였는지 혹은 공유되 였는지를 정의하며 함수는 초기 화된 핵심안 
색 인마디 에 대 한 지 적자를 귀 환시 킨 다. 이 조작은 보통 파일 부분에 대 한 검 색 으로 실 
현된다. 색인마디는 증가된 색인마디의 vnode 참조계수값으로 잠금되며 귀환된다. 다른 
것들은 동일한 색 인마디 에 대 한 참조값을 가질수 있으며 색 인마디잠금은 구조체 에 대 
한 접근을 동기화하는데 리용된다. 
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2 단계(색인마 a 의 찾가) 

프로쎄스가 색 인마디를 일 단 포착하면 그것을 찾는다. 만일 프로쎄스가 색 인마디 
를 변경시키려고 하면 색인마디는 독점적으로 잠그어 진다. 그러나 만일 색인마디를 
읽기만 하면 색인마디는 공유된 상태에서 잠그어 진다. 실제적으로 색인마디들은 보 
통 lookupnameO , 부분프로그람에 의 하여 탐색 되 기 때 문에 사용자는 보통 한개 의 참조 
값을 가지고 inode/vnode 를 얻지만 잠금은 하지 않는다. 다음 사용자는 xfs _ ilock () 를 
호출하여 색 인마디 를 명 백하게 잠근다. 일 단 색 인마디 가 잠금되 면 그것 을 유지 하고 
있는 프로쎄스는 임의의 마당으로부터 읽을수 있다. 하지만 색인마디가 거래의 문맥 
으로될 때는 변경만 할수 있다. 

3단계(색인마 O 의 변경) 

색인마디가 변경되려면 독점적으로 잠그어 져 있어야 한다. 호출자가 거래지적자를 
취 하는것을 제 외 하고는 xfs _ iget () 와 꼭같은 cfs _ tams _ iget () 를 호출하여 색 인마디를 엄지 
않으면 xfs _ ilock () 의 호출에 의 하여 독점 적 으로 잠그어 지 며 xfs _ trans _ ijoin () °] 호출에 따 
라 거래에 첨부된다. 이 조작이 수행되기만 하면 색인마디를 변경할수 있다. 색인마디에 
대 한 모든 변화가 이 루어 지 면 거 래공정 은 색 인마디내 에서 무엇 이 변경되 였는가를 통보 
해야 하며 따라서 가동일지에 기록되여야 한다. 

4단계(색인마 a 변경에 대한 가동일지등록) 

색 인마디 에 대 한 변경 은 xfs _ trans _ log _ in _ ode () 함수를 리용하는 색 인마디 의 한 부분으 
로서 가동일지 에 기 록될 수 있 다. 이 함수는 색 인마디 의 부분들이 변경되 였 다는것 을 지 적 
하는 기 발들을 얻 고 가동일지 에 기 록할 필요가 있다. 기 발들은 모두 xfs _ inode _ item_h 안에 
정의되며 이 장의 다음 부분에서 구체적으로 서술될것이다. 

5단계(색인마 a 의 개방) 

일단 프로쎄스가 색인마디를 찾고 변경시키면 그 색인마디는 잠금을 해제하여야 하 
며 개방되여야 한다. 만일 색인마디가 거래의 부분으로 리용되지 않았으면 프로쎄스는 
색 인마디의 잠금을 해제할 xfs _ iput () 를 쉽 게 호출할수 있으며 색 인마디의 vnode 에 대 한 
참조값을 개방한다. 만일 색인마디가 거래의 부분으로 사용되고 있으면 프로쎄스가 
xfs _ trans _ commit () 를 호출할 때 색인마디는 잠금해제되며 그것의 참조값도 해제된다. 만 
일 프로쎄스가 결속을 완료한후에도 색인마디우에 계속 유지되려고 하면 거래를 결속하 
기전에 xfs _ toms _ ihold () 를 호출할 필요가 있다. 이것은 거래코드는 거래가 결속될 때에는 
색 인마디의 잠금을 해제 하거 나 개 방하지 않는다는것을 말한다. 

6 단계(색인마 o 변경의 재쓰：비 

색인마디가 거래의 한 부분으로 변경될 때 변경된 색인마디구조체는 기억상태에 있 
으며 그 변경내용은 디스크상의 가동일지에 기록된다. 어떤 점에서 색인마디는 xfs _ sync () 
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를 호출하는 bdflush() 에 의하여 혹은 다른 색 인마디 로써 사용할것 을 요구하는 색 인마디 
구조체 에 의하여 디스크상의 홈 (home) 에 재쓰기될수 있다. 이 경우에 색 인마디에 대한 모 
든 변경들은 이 점에서 디스크에 재쓰기되며 디스크상의 가동일지복사는 파일체계회복에 
더 이상 필요없게 된다. 

7 단계 ( 색인마디구조체의 해제) 

우에서 언급한바와 같이 색인마디구조체는 어떤 점에서 다른 색인마디를 리용하기 
위하여 재생될수도 있다. 이 경우에는 색인마디의 기억이 개방되고 그 어떤 다른것에 재 
리 용되 므로 핵 심 안 색 인마디 의 생 명 주기 가 끝나게 된 다. 

색인마디의 배정 

핵심안 색인마디들은 xfs()_iget() 의 호출에 의하여 배정된다. xfs_iget() 의 함수원형은 
다음과 같다. 


xfs_inode_t*xfs_iget(xfs_mount_t*mp, xfs_trans_t*tp, xfs_ino _ tino, unit flags) 


호출자는 파일체계의 올려태우기구조체에 대한 지적자와 만일 거래를 실행하면 거 
래 지 적 자를 주며 요구되 는 색 인마디 의 색 인마디 번호 그리 고 색 인마디 가 공유방식 에 서 
잠금되 였는지 독점 방식 에서 잠금되 였는지를 지적 하는 기 발들을 준다. 함수는 요구한 
색인마디의 핵심안 판본에 대한 지적자를 귀환시킨다. 색인마디는 요청된 방식에서 잠 
금된 호출자에게 귀환된다. 색인마디의 마당들은 디스크상의 색인마디의 양식에 따라 
채워 지게 된다. 만일 색인마디파일자료가 디스크상의 색인마디안에 전체적으로 일치 
한다는것 을 의 미 하는 LOCAL 양식 으로 되 여 있 으면 i_ul. iu_data 가 파일 내 용을 가지 고 
있는 기 억내배 렬을 지적하게 되며 : i_byte 는 배 렬안의 바이트번호를 포함하게 된다. 이 
배 렬은 파일 자료가 32byte 와 같거 나 작으면 i_u2. iu_inline_dataarray 로 되거 나 혹은 핵 
심 부히 프로부터 배 정 된 배 렬 일 수 있 다. 만일 파일 의 길 이 가 0이 면 i_ul. iu_data 는 
NULL 로 되 며 i_byte 는 0으로 된 다. 또한 색 인마디 가 EXTENTS 양식 이 면(파일 의 자료가 
디스크상의 색 인마디와 일치되지 않지만 색 인마디 에 대 한 범위서술자이라는것을 의미 
하는) i_ul. iu_extent 는 파일의 범 위서 술자를 포함하는 기 억 내 배 렬을 지 적 할것 이며 
i_byte 는 배 렬안의 바이트번호를 포함할것 이 다. 이 배 렬은 한개 혹은 두개의 범위 만 있 
으면 i_ul. iu_inline_ext array 일수 있거 나 혹은 핵 심부의 히 프로부터 배정된 배 렬 일수 
있다. 파일의 길이가 0이면 i_ul. iu_extent 는 NULL 로 되며 i_byte 는 0으로 될것이다. 
XFS_IEXTENTS 기 발은 i_flags 에 설정 된다. 이 기 발은 파일의 모든 범위 서 술자를 읽 을 
수 있 으며 i_ul. iu_extents 배 렬 안에 있 다는것 을 지 적 한다. 

만일 색 인마디 가 파일 이 디 스크상의 색 인마디 에 일 치시키 기 위한 범위서술자가 너무 
많다는것 을 의 미하는 B 나무양식 이면 i_broot 는 파일 의 범 위 B 나무뿌리 를 포함하는 기 억 
내 배 렬을 지 적 할것 이며 i_broot_byte 는 배 렬 안의 바이 트수를 포함할것 이 다. 또한 
XFS_IEXTENTS 기발이 i_flags 에 설정되면 i_ul. iu_extents 는 우의 경우에서와 같이 파일의 


294 



모든 범위들을 포함하는 배렬을 지적할것이다. 만일 기발이 령으로 설정되면 범위는 여 
전히 읽을수 없으며 필요하다면 xfs _ ireadindir () 로 호출하여 읽 어야 한다. 큰 범위들을 가 
지는 파일의 모든 범위들에 대한 읽기는 간단히 파일의 stat () 로 효과적으로 수행될수 있 
다. 귀환된 색인마디는 매 파일당으로 핵심안 색인마디하쉬표로 하쉬화된다. 우리는 모든 
파일체계를 위한 전통적인 단일하쉬표로부터 체계의 유연성을 개선하기 위하여 매 파일 
당 하쉬표로 방향을 바꾸었다. xfs _ iget () 의 호출은 우선 디 스크로부터 색 인마디 를 옮겨 
쓰기전에 이 하쉬표에서 요구되는 색인마디를 찾는다. 핵심안 색인마디는 오직 재생될 
때 만 하쉬표로부터 제 거된다. 색 인마디 는 또한 파일체 계 의 올려태우기구조체 에 첨부된 목 
록우에 배치될수도 있다. 이 목록은 xf S _ S yn C () 와 같은 부분프로그람에서 모든 핵심 안 색 
인마디 를 추적하는데 리 용된 다. 

색인마디의 직접삼입자료/범위 / B 나무뿌리 

이 부분은 iu _ data , iu _ extents , i _ broot 마당들의 조종을 서술한다. 이 마당들은 범위가 
파일의 크기변화만큼 변화되 여 야 할 배 렬을 지 적한다. 

iu-data 

색 인마디배정 에 대 한 부분에서 서 술된바와 같이 이 마당은 LOCAL 양식 으로 색 인 
마디의 직결자료를 포함하는 배렬을 지적한다. 이 양식의 파일크기가 변화될 때 크기 
를 변 경 시 키 는 프로쎄 스는 핵 심 안 배 럴 의 크기 를 재 설 정 하기 위 한 xfs _ idata _ realloc () 
를 호출해야 한다. 이 함수는 필요되는 바이트수로 델타 ( delta ) 를 취한다. 만일 델타가 
정 이 면 배 럴 에 더 많은 기 억 이 배 정 되 며 부이 면 더 작아 진 다. 만일 크기 가 령 으로 
되면 iu_data 는 NULL 로 된 다. 만일 크기가 디스크상의 색인마디에 일치되는것보다 
더 커지게 되면 프로쎄스는 LOCAL 양식으로부터 EXTENTS 양식으로 변화시키기 위 
하여 거래를 수행하도록 크기를 변경시켜야 한다. 그러 한 거래의 한 부분으로서 직결 
자료가 가동일지에 기록되 여 야 하며 iu _ data 배 렬은 xfs _ idata _ realloc () 를 호출하여 개 방 
되여야 한다. 그리고 색인마디의 범위를 위한 배렬은 xfs _ iext _ realloc () 을 호출하여 
iu _ extentes 에 배정되여야 한다. 


iu_extents 

색 인마디 가 EXTENTS 나 BTREE 양식 에 있으면 이 마당은 그 색 인마디 에 관한 모든 
범위서술자들을 포함하는 배 렬을 지적한다. 만일 파일 이 EXTENTS 양식 에 있으면 이 배 
렬은 파일의 길이 가 0이 아닌 이상 존재하는것으로 담보된다. 만일 파일이 BTREE 양식 이 
면 이 배렬은 첫번째로 요구될수도 있으며 그의 존재는 색인마디의 기발마당의 
XFSJEXTENTS 에 의 하여 표현된다. 파일에서 범위의 수가 변할 때 프로쎄 스는 핵심 안 
배 렬의 크기 를 재설정 하기 위 하여 xfs _ iext _ realloc () 를 호출해 야 한다. 이 함수는 필요한 
범위의 수에서 델타를 취하고 필요한 배정만큼 배럴의 기억을 개방한다. 범위의 수가 0 
으로 되면 iu _ extents 는 NULL 로 설정된다. 만일 범위의 수가 아직 채 결정되지 않은 턱값 
을 초과하면 배렬은 더 커지지 않고 블로크넘기기코드는 캐쉬의 B 나무를 통한 접근속 


295 



도가 더 떠지게 된다. i u _ extents 배렬은 파일변화에 따라 정렬된 색인마디의 모든 범위를 
포함한다. 이 변위값은 파일디스크블로크의 위 치를 빨리 찾기 위한 블로크넘기 기코드에 
리 용된다. 이 조작은 직 렬접근검색의 효과성 을 개선하기 위하여 단일입구점캐쉬 로 더욱 
강화된 배 렬의 2진람색 에 의하여 수행 된다. 


iujbroot 

색 인마디 가 BTREE 양식일 때 이 마당은 디스크상의 색 인마디의 B 나무뿌리의 핵심안 
복사를 지 적한다. 우에 서 언급된 다른 배 렬과 같이 이 배 렬은 사용된 B 나무뿌리부분을 
유지하기 위하여 충분한 기억을 확보하며 뿌리가 커지거나 줄어 드는것만큼 동적으로 크 
기 를 다시 설정 하여 야 한다. 이 조작은 xfs _ iroot _ realloc () 의 호출에 의 하여 실현되 는데 이 
함수는 요구된 B 나무레코드의 수를 변화시 킨다. 이 부분프로그람은 B 나무뿌리의 양식을 
파악하며 크기 를 변경시 킬 때 적 당한 값으로 뿌리안에 존재하는 정 보를 움직 인 다. 뿌리 
의 크기 가 일부 레 코드에 의하여 증가할 때 는 레 코드에 대 한 지 적 자들이 자료구조체 의 
끝을 향하여 옮겨 지며 크기가 줄어 들 때는 지적자들이 앞으로 옮겨 진다. B 나무뿌리의 
레 코드수가 0으로 될 때 자료구조체 에는 B 나무블로크머 리 부에 그 값이 계 속 남아 있 기 
때문에 개방되지 않는다. 더 이상 필요없으면 프로쎄스는 뿌리를 포함하는데 리용된 기억 
을 개 방하기 위 하여 xfs _ iroot _ free () 를 호출해 야 한다. 이 과정 은 색 인마디 가 더 이 상 
BTREE 양식 에 있지 않을 때만 수행된다. 

i_byte 와 i_broot_bytes 

이 두개의 계수기는 대 응하는 iu _ data / iu _ extents 와 i _ broot 마당들에 의 하여 지적되는 
배 렬에 리 용된 바이트들을 추적 한다. 당분간 iu _ inline _ data / iu _ inline _ ext 배 렬의 리 용을 제 
외하고 배렬들은 정확히 요구되는 크기에 있다. 이것은 우리가 kmem _ realloc () 를 호출해 
야 하거 나 혹은 xfs _ i 네 realloc () 부분프로그람들중의 하나가 호출될 때 마다 매 번 그와 류 
사한 어떤 함수를 호출해 야 한다는것 을 말한다. 우리 는 kmem 의 호출수를 줄이 려 고 사용 
하는것보다 더 많은 기 억을 유지 하지만 현재 더 좋은 기 억리용을 추구하여 상업화되고 
있다. 이것이 cpu 의 주기로 환산하여 고도의 휴지시간해결책으로 된다면 그것을 변경시 
킬수 있다. 

색인마디잠금 

우에 서 언급한바와 같이 색 인마디 는 공유방식 이 나 혹은 #점방식 으로 잠금을 실 현할 
수 있다. 이것은 같은 색인마디에 대하여 동시에 여러명의 읽기를 수행할수 있다는것을 
의 미한다. 이 때 동일한 색 인마디 는 다중읽 기조작과 파일의 비배정쓰기조작을 병 렬로 진 
행할수 있 어 야 한다. 동시파일 접 근은 비 동기!/ O 와 등록부에 관하여 특별 히 중요하다. 우 
리의 비동기！/ O 실현은 스레 드에 기 초하고 있으며 따라서 같은 시 각에 여 러개의 스레드가 
파일에 접근하게 하는것은 크고 구획으로 분할된 기록권들과 갈은 장치들의 성능을 높이 
기 위한 관흐름식 ！/0요청 을 증가시 킨다. 등록부들은 쓰는것 보다 더 자주 경 로탐색 을 진 
행하여 읽을수 있으며 따라서 일반 장치들에 대 한 병 렬접근가능성으로 하여 경 로결정성 
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능을 더욱 높일수 있게 한다. 이것은 다른 파일 체 계 에 서 의 주목하는《병목》문제로 되 
며 따라서 이것은 한걸음 더 전진한것으로 된다. 색인마디잠금은 색인마디내용갱신을 위 
하여 독점적으로 유지되여야 한다. 이때 색 인마디의 내용은 디스크상의 색 인마디에 포함 
된 모든 마당들을 포괄하며 필요하면 다른것들도 포함한다. 

색인 마디거래와 가동일지 등록 

디스크상의 색인마디에 반영될수 있는 색인마디의 모든 변경내용은 거래의 문맥안에 
서 이루어 져야 하며 그 거래 안에 가동일지에 기록되여야 한다. 이와 관련하여 유일하게 
제외되는것은 다음 부분에서 서술하게 될 색 인마디상에서의 접근，변경，수정회수일수도 
있다. 일단 색인마디가 수정되면 거래기법은 xfsJrans_log_inode() 를 호출하여 그 변경을 
알려야 한다. 이 함수는 색 인마디부분들이 변화되 였 다는것 을 지 적하는 기 발모임 을 장악 
한다. 기 발들에는 다음과 갈은것 들이 있 다. 

▼ XFS_ILOG_META: 이 기발은 i_d 부분구조체의 임의의 마당이 변경되면 정의되여 
야 한다. 

• XFS_ILOG_DATA: 이 기발은 색인마디의 직결자료가 변화되면 정의되여야 한다. 

• XFS_ILOG_EXT: 이 기 발은 iu_extents 배 럴 이 변경 되 고 파일 이 EXTENTS 양식 이 면 
정의되여야 한다. 

• XFS_ILOG_BROOT: 이 기 발은 파일 이 BTREE 양식 이 고 i_broot 배 럴 의 내 용이 변경 
되면 정의되여야 한다. 

▲ XFS_ILOG_DEV: 이 기 발은 i_u2.iu_rdev 마당이 변경 되 면 정의 되 여 야 한다. 이 기 발 
들은 현재 거래가 결속될 때 색인마디의 부분들이 가동일지에 기록되려고 한다는 
것을 거 래코드에 알려 준다. 매 정의부분은 입구점 안의 가동일지 에 기록되며 그리 하 
여 XFS_ILOG_META 의 정의는 핵심안 색인마디에 매몰된 전체 xfs_dinode_core 구조 
체로 가동일지에 기록하며 XFS_ILOG_ BROOT 의 정의는 전체 B 나무뿌리를 가동 
일지에 기록하게 될것이다. 우리는 작은것 즉 색인마디의 작은 부분들에 대하여 
서 는 가동일 지 에 기 록하지 않는다. 왜 냐하면 작은 부분들을 추적하는데 소비 되 는 
휴지 시 간은 그것 들을 가동일 지 에 복사하는것 만큼 높아 지 기 때 문이 다. 

색인마디를 조종하는 거래가 결속될 때 색인마디는 잠금해제되며 색인마디에 대한 
참조는 개방된다. 

색인마디소거 

변경된 색인마디들은 bdflush 데몬을 호출하는 방법으로 디스크에 대하여 소거되거나 
색인마디의 가동일지이메지가 가동일지의 뒤쪽에 너무 멀리 있을 때 거래관리코드에 의 
하여서도 소거된다. 색 인마디는 색 인마디의 변경으로부터 다른 프로쎄스를 보호하기 위 
하여 공유방식으로 잠금되여 야 하며 디스크에 기록되는 동안에 다른 프로쎄스가 색 인마 
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디를 찾을수 있게 한다. 다중프로쎄스들은 색인마디들을 동시에 소거하려고 할수 있기때 
문에 i_flock 는 색 인마디의 소거를 표기화하는데 리용된다. 이 조작은 성능과 함께 정확 
성을 다같이 필요로 한다. 성능에 관하여서는 불필요한 작업을 할 필요가 없다. 정확성에 
관하여 서 는 거 래 관리 코드에 의하여 얻 어 진 색 인마디 에 대 한 참조값이 리 용되 지 않거 나 
혹은 다중프로쎄 스에 의하여 개 방되 지 않는다는 사실 을 확인해 야 한다. 일 단 참조값이 
개 방되면 색 인마디가 재생될수 있다. 따라서 한개 프로쎄스만은 참조값이 색 인마디를 보 
호할수 있 다고 가정할수 있 다. 

색 인마디 의 실제 적 소거 를 수행 하는 부분프로그람은 xfs_iflush() 이 다. 이 부분프로그 
탐은 캐쉬로부터 색인마디의 디스크블로크에 해당한 완충기를 엄을수 있게 하며 색인마 
디를그 완충기에 복사하고 디스크에 완충기를 동기적 혹은 비동기적으로 혹은 일정한 
지연을 가지고 재쓰기할수 있게 한다. 만일 색인마디가 기억에 꼭 붙잡혀 있으면(아직 디 
스크에 결속되지 않은 트랙잭션의 한부분이기때문에) 이 부분프로그람은 알려 질 때까지 
대 기하게 된다. 만일 색 인마디 가 붙잡혀 있지 않으면 그 부분프로그람은 xfs_iflush_done() 
과 완충기 의 b_iodone 함수에 대 한 색 인마디 가동일지 항목 그리 고 b_fsprivate 지 적 자를 붙인 
다. 이 부분프로그람은 Active Item List (AIL) 쓰기가 완성될 때 실행되게 된다. 목적은 체 
계 의 능동항목목록 (AIL) 으로부터 색 인마디 를 제 거하며 색 인마디 지우기 를 표시하며 거 래 
코드에 의하여 얻 어 진 색 인마디 에 대 한 참조를 개 방하는데 있 다. 끝으로 색 인마디 는 지 
워 졌다는것과 잠금이 해제되 였다는것 그리 고 완충기쓰기 가 시 작되 였다는것을 표시한다. 

완충기 가 xfs_iflush() 로 잠금이 해제 되면 쓰기를 완료하고 xfs_iflush_done() 를 실행하 
기전에 색인마디가 다시 낡아 질수 있다. 이 경우에는 색인마디가 AIL 의 앞쪽으로 옮겨 
진다. 한편 xfs_iflush_done() 에 의 하여 완료되는 소거는 AIL 로부터 색 인마디를 제거 할 권 
한을 가지고 있지 못한다. 

이것을 조종하기 위 하여 xfs_iflush_done() 은 다음과 같은 동작을 수행 한다. 

▼ 먼저 AIL 의 잠금(이 마당을 보호하는)을 취하지 않고 색인마디의 LSN 을 찾는다. 
만일 그것 이 변경되 였으면 색 인마디 가 AIL 에 옮겨 졌거 나 옮겨 지 고 있으며 이 
에 대 하여 우려하지 않아도 된 다. 

• 만일 값이 변경되였으면 AIL 의 잠금을 얻고 값이 아직 변경되지 않았으면 AIL 로 
부터 색 인마디 를 제 거한다. 

• 다음 색인마디의 i_fl 0C k 를 개방한다. 

▲ 마지막으로 색 인마디에 대한 참조값을 개방한다. 

일단 참조값이 개방되면 더이상 조종할수 없거나 색인마디를 찾을수 없다. 여기서 
디 스크쓰기 가 발생하는 동안 다시 색 인마디 를 지 적하는 색 인마디참조값으로 어 떤 특별 한 
동작은 수행하지 않는다는데 대 하여 강조해 둔다. 색 인마디 는 잠금을 해 제 하기전 에 
xfs_i_flush() 로 지 우기 가 표기되 기때 문에 기 록하는 동안에 색 인마디 를 변경시키 는 임의의 
프로쎄스는 거 래코드에 관한 다른 참조값을 엄 게 된 다. 
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색인마디재생 


어떤 시점에서 xfs_reclaim() 의 호출은 참조되지 않는 색인마디를 재생시키려고 할것 
이다. 색인마디는 이 시점에서 참조가 없다는것을 담보하므로 색인마디가 낡아 지지 않았 
다는것을 알수 있다. 이제 해야 할 조작은 색인마디와 련관된 임의의 변경된 파일자료를 
소거하며 핵심 안 색 인마디의 올려태우기구조체의 목록으로부터 색인마디를 제거하며 색인 
마디와 관련된 모든 기억을 개방하는것이다. 

XFS 상우 I 블로크구조체와 조작 

상위블로크는 대다수의 거래에 의하여 변경되는 중심적인 자원이다. 이것은 상위블 
로크가 병목현상에 대 하여 높은 잠재 력을 가진다는것을 의미 한다. 이것은 일단 거래가 자 
원을 변경하면 그 자원은 처음으로 결속될 때까지 다른 거래에 보여 질수 없기때문이다. 
상위블로크와 갈은 자원이 많은 거래에 의하여 접근되고 매개가 일정한 시간동안 자원을 
유지하면 거래는 자원의 접근을 기다리면서 병목화될것이다. 이러한 현상을 방지하기 위 
하여 XFS 에서 상위블로크는 잠금을 유지 하는 시 간을 최 소화할수 있게 설계 된 부분프로 
그람들을 통하여 변경되게 될것이다. 상위블로크가 변경되는 리유는 상위블로크가 파일 
체계의 전체 색인마디의 수，자유색인마디의 총수，자유블로크의 총수를 포함하고 있기때 
문이 다. 이 계 수기 들은 대 다수시 간 변경되 며 따라서 최 량화되 는 값들로 갱 신되 게 된다. 
공통적 인 경 우에 대 하여 최 량화의 일 반규칙 에 관하여 일 관하지 만 상위블로크에 대 한 갱 
신이 완전히 공통이면 상위블로크의 다른 마당들은 거래안에서 때때로 변경될것을 요구 
하게 된다. 이러한 비공통적경로에 대한 대면부는 어떠한 객체도 중단시킴이 없이 이 마 
당들을 가지 고 작업해 야 한다. 이 모든 내 용은 역시 상위블로크의 핵심안복사에 대 한 접 
근과 대응되 여 야 한다. 

상위블로크완충기 

표준 getblk()/bread() 경 로를 거 처 접근되 는 공통적 인 캐쉬 에 보존하지 않고 XFS 상위 블 
로크는 파일 체 계 에 대 하여 전통화한 완충기 에 보존되 게 된 다. 캐 쉬코드가 bdflush() 에 서 
수행한것과 같은 이 방법 은 상위블로크완충기와 전혀 호상작용하지 않는다. 물론 이것은 
상위블로크가 요구될 때마다 디스크에 대하여 소거된다는것을 확인하여 야 한다는것을 의 
미한다. xf S _sync() 부분프로그람이 주기 적 으로 호출되 기때 문에 필요할 때 그로부터 상위 블 
로크를 소거하는것 이 보다 효과적 이 다. 

상위블로크완충기 는 올려태 우기구조체 에 보존된 지 적 자에 의하여 쉽 게 지 적할수 있 
다. 완충기 에 대 한 접근은 아래 에서 구체적 으로 서 술되 는 xfs_getsb() 와 xfs_toms_getsb() 부 
분프로그람을 통하여 진행된 다. 이 부분프로그람들은 상위블로크완충기 에 대 한 접 근을 
동기 화할 목적 을 가지 고 있 다. 완충기 는 오직 올려태 우기 시 에 디 스크로부터 만 읽 어 지 게 
되며 그 다음 완충기는 상위블로크의 디스크우복사로 sync 에 보존되게 된다. 이것은 상위 
블로크에 대 한 접근이 I/O 동작 등으로 지 연되지 않는다는것을 담보해 야 한다. 왜 냐하면 
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다른 지원들도 완충기에 재생을 강하게 요구하고 있기때문이다. 

상위블로크완충기가 거래기간에 잠금을 유지하는 시간을 최소화하기 위하여 상위 
블로크는 실제적으로 거래가 결속되기전에는 잠금되거나 변경되지 않는다. 이것은 디 
스크로부터 다른 자원들을 읽어 들이거나 다른 거래에 의하여 개방되기를 기다리는 동 
안에 완충기 가 잠금을 유지 하지 않는다는것 을 담보한것 이 다. 갱 신과정 이 절 대 수값보다 
도 계수기에 더해지거나 그로부터 떨어 지는 값을 포함하기때문에 공통적인 경우에 이 
조작은 계수기에 관하여 잘 진행된다. 이 갱신값들은 거래의 정확성을 보장하면서 끝 
까지 지연될수 있다. 거래의 사용자는 이전 변화가 상위블로크에 xfs _ trans _ mod _ sb () 의 
호출을 적 용할 필 요가 있 다는것 을 지 적하게 된다. 이 부분프로그람은 요청된 변화를 
기록하며 거래의 부분으로서 상위블로크에 적용된다는것을 보증해야 할 책임을 지고 
있 다. 

계 수기 와 다른 상위블로크의 마당들이 변경 되 여 야 할 때 상위블로크완충기 는 
xfs _ 仕 ans_ge 比) lk ()/ xfs _ 仕 ans _ bread () 보다는 오히 려 완충기 가 xfs _ toms _ getb () 의 호출로 얻 어 
져야 한다는것을 제외하고는 임의의 다른 완충기로서도 접근될수 있다. 상위블로크완충기를 
리 용하는 xfs _ trans _ log_bufO 에 대 한 호출은 잘 진행 되 며 xfs _ trans _ mod _ sb () 의 리용과 혼합될 
수도 있다. 

핵심안 상위블로크는 파일체계에 대한 정적정보만이 아니라 체계의 요약정보를 찾는 
데 도 리용될 수 있 다. 상위블로크완충기 로는 그 어 떤 변화가 이 루어 질 때 만 접 근하여 야 
한다. m _ sb_lock 에 의하여 변화가 보호되는 핵심 안 상위블로크의 마당들은 올려태우기구 
조체 의 잠금을 회 전 한다. 이 잠금은 람색 되 고 있는것 이 일 치하다는것 을 담보하는데 리 용 
될수 있다. 핵심안 상위블로크를 변경시키는 코드는 거래가 상위블로크결속을 한후에 갱 
신을 보호하기 위하여 이 잠금을 리 용한다. 

상우 I 블로크관리대면부 

xfs _ trans _ mod _ sb () xfs _ trans _ mod _ sb () 의 호출은 상위 블로크를 즉시 잠금하지 않고 상 
위 블로크의 계 수기 들을 변경시키 는데 리 용된 다. 

함수의 원형은 다음과 갈다. 

Void xf s_trans_mod_sb (xf s_trans_t *tp, unit field, int data); 

마당의 인수들은 델타파라메터에 넘겨 진 계수기가 더해야 한다는것을 정의한다. 열기 
를 진행하기 위하여서는 주어 진 계수기로부터 부의 값이 델타에 넘겨 져야 한다. 

마당파라메 터의 유효값들은 다음과 갈다. 

▼ XFS _ SB _ ICOUNT : delta 를 sb_icount 마당에 준다. 

• XFS _ SB _ IFREE : delta 를 sb_ifree 마당에 준다. 

• XFS _ SB _ FDBLOCKS : delta 를 sb_fdblocks 마당에 준다. 

▲ XFS _ SB _ FREXTENTS : delta 를 sb_frextents 마당에 준다. 
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xfs _ ttans _ commit () 가 호출될 때 상위 블로크완충기는 거래에 의 하여 잠그어 지며 정의 
된 델타 ( delta ) 모두가 함수에 적용된다. 델타는 루적되며 따라서 같은 마당이 주어 진 
거래 안의 xfs _ trans _ mod _ sb () 에 대한 다중호출로 정의될수도 있 다. 일단 거래를 결속하면 
델 타는 상위 블로크의 핵 심 안 복사에 적 용될 수도 있 다. 

xfs _ trans _ getsb () 호출은 거 래안에 서 상위블로크완충기 를 잠금하는데 리 용된 다. 이 조 
작은 거래 가 xfs _ toms _ mod _ sb () 의 호출에 의 하여 변경될수 있는것보다는 다른 상위블로크 
의 마당들을 변경시키 는것 이 필 요할 때 만 리용될 수 있다. 이 함수의 결 과는 
xfs _ trans _ bread () 와 곡 같지 만 상위 블로크를 엄 는데 만 리 용된 다. 

함수의 원형은 다음과 갈다. 


buf_t*xfs_trans_getsb(xf s_t ran s_t * tp); 

완충기 는 xfs _ trans _ brelse () 의 호출에 의 하여 개 방될 수 있 다. 특정 한 호출이 필 요되 는 
일은 없다. 

xf S _ get S b () 의 호출은 그것 이 거 래의 앞에서 리용될수 있다는것 을 제 외 하고는 
xfs _ toms _ getsb () 와 꼭 같다. 이 함수는 잠금과 상위블로크완충기를 귀환시킨다. 그러나 이 
완충기는 절대로 변경시킬수 없다. 왜냐하면 상위블로크는 거래내에서만 갱신될수 있기때 
문이 다. 정보가 요구한 시간의 대부분은 핵심안 상위블로크로부터 리용될수 있으며 따라서 
이 함수의 리용은 제한되고 있다. 

함수의 원형은 다음과 갈다. 

buf_t*xf s_getsb (xf s_mount_t*mp) ; 

xfs _ mod _ iucore _ sb () 은 상위 블로크의 핵 심 안 복사를 변경 시 키 는데 리 용된다. 

이 함수의 원형은 다음과 갈다. 

int xfs_mod_incore_sb(xfs_mount_t*mp,unit field,int delta); 

마당파라메터는 상위블 로크 마당이 주어 진 델타에 적용된다는것을 지적한다. 이 부 
분 프로 그람은 핵심안 상위블 로크를 보호 하는 회전잠금을 조심히 다룬다. 현재 이 프로 그 
람은 우에 서 정 리 한 xfs _ trans _ mod _ sb () 를 통하여 리용할수 있는 마당의 갱 신을 지 원 하지 
만 필요하면 그 기능을 확장할수 있다. 

이 프로그람은 단위블로크의 계수기들이 절대로 령이하로 될수 없다는것을 강하게 
가정 하고 있다. 만일 델 타가 그런 조건을 발생할수 있게 정의되 면 그 델 타는 적 용될수 
없으며 HNVAL 을 귀환하게 된다. 

xfs _ mod _ incore _ sb _ batch () 의 호출은 상위 블로크의 다중델 타를 다중마당에 적 용하 
는데 리 용한다. 이 함수는 매개가 마당과 그 마당의 델타를 정의 하는 xfs _ mod _ sb_t 구 
조체의 배럴을 취한다. 다중델타를 정의하기 위하여 호출자가 상위블로크에 그것을 
적용할수 있게 함으로써 이 프로그람은 다중델타가 자동적으로 적용될수 있게 하며 
xfs _ mod _ incore _ sb () 에 대 한 호출을 다중화하는데 필 요한 잠금휴지시 간이 줄어 들게 한다. 
함수의 원형과 xfs _ mod _ sb _ t 정의는 다음과 같다. 
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typedef struet xfs_mod_sb 


unit msb_field ； /* msb_delta 를 적 용하기 위 한 마당*/ 

int msb.delta ; /* 정의된 마당에 더 해 야 할 량 */ 
xfs_mod_sb_t 

xf s_mod_incore_sb_batch (xf s_mount_t*mp, xf s_mod_sb_t 
*msb,uint nmsb) ; 

xfs_mod_incore_sb() 와 같이 이 부분프로그람은 상위블로크를 보존하는 잠금을 조종 
하며 상위블로크의 계수기가 령으로 되지 않게 강한 제한을 준다. 만일 정의된 임의의 
델 타가 그러한 조건을 만족시키 면 적 용될 델 타는 하나도 없 으며 함수는 HNVAL 을 귀 환 
시킨다. 

디스크구조 

XFS 의 설계 에서 공간배 치구조의 선택 은 대 규모파일과 파일체 계 의 효과적 지 원요구에 
따르는 영 향을 받았다. 앞에 서 설 명한것 처 럼 공간관리기 는 파일안의 블로크배 치구조의 
최량화，매 파일의 보증정보의 결정，디스크상에서 서로 가까운 관계에 있는 파일들의 
보존에 관한 역 할을 수행한다. 공간관리 에 대 한 구체 적 인 내 부자료는 사용자가 파일 을 
충분히 련속적으로 배치하였는지 아니면 보다 련속적으로 배정할 파일공간이 있는지를 
결정할수 있게 하는것 을 제 외 하고는 사용자로부터 숨겨 지 며 또 이 름관리기 계 층으로부터 
도 숨겨 진다. 제기된 모든 대면부들은 호출에 기초하며 통보문에는 기초하지 않는다. 조 
종과 관리 통보는 다른 마디 로부터 볼수 있으나 체 계호출과 관리 층에 의하여 조종되 게 되 
며 국부호출로 귀환된다. 

디스크상의 구조 

상위블 로크는 모든 파일체계정보의 뿌리 이다. 이 블 로크는 파일체계의 앞부분에 배 
치 된다(변위 0, Linux 하에 서 는 LILO 와 충돌할수 있기 때 문이 다.). 이것 은 전통적 인 UNIX 
파일 체 계 의 속성 과는 차이난다. UNIX 는 변위 512 에 서 출발한다. 

XFS 와 다른 Linux 파일체계와의 혼돈을 피하기 위하여 XFS 파일체계의 변위 512 는 
다른 파일체계의 상위블로크의 매지크번호와 다른 값을 포함해 야 한다. 상위블로크는 파 
일체계 의 다른 모든 요소들을 찾는데 충분한 정 보를 가지 고 있 다. 올려태 우기된 파일 체 
계 에 속하는 정 보부분인 상위블로크의 한개 의 복사판이 있 다. 

다음의 마당들은 상위블로크에 서 가장 중요한 마당들이다. 

▼ XFS 매지크번호 

• XFS 판본 

• 파일체계의 유일 id 
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• 마지막으로 올려태우기된 파일체계이름 

• 론리적블로크크기 (lbsz 바이트크기로 29..216) 

• 신뢰할수 없는 범 위 크기 (lbsz 로) 

• 물리적쌕터크기(바이트) 

• 색인마디크기(바이트， 27..211) 와 색인마디의 매 자료대역과 속성대역의 최소크기 
와 같이 색인마디의 공간을 어떻게 분할하는가에 대한 정보 

• 자료블로크배 정 기 술，비 트매 프의 선 택 이 나 B 나무，기 타 

• 색인마디에 배정된 작은 파일 

• 배 정그룹크기 (lbsz) 

• 총 파일 체 계자료부분一기 록권크기 (lbsz 로) 

• 총 파일체 계 의 신뢰할수 없는 부분기 록권크기 (extent 단위 로) 

• 신뢰할수 없는 부분기록권범위에 대한 비트매프의 론리적블로크번호 

• 신뢰할수 없는 부분기 록권비 트의 요약정보론리 적 블로크번호 

• 배정 혹은 자유색인마디의 총수 

• 빈 자료부분 기록권블로크의 총수 

▲ 자료와 자료부분기록권의 메타자료로 배정된 블로크들의 총수 

표준조작시 에 변화되는 마당들은 오직 (년에 의하여 리 용된 정 보를 포함하는 정적마 
당들만이다. 

이 정보들의 변화는 재기동과정 에 정 보를 받을수 있는지 없는지 에 관한 파일체 계의 
일 관성 보존을 위하여 가동일 지 에 기 록되 여 야 한다. 바꾸어 말하면 올려 태 우기 시 에 정 보가 
계 산될수 있으나 디 스크에 는 전혀 기 록될수 없다(올려 태 우기 시 를 제 외 하고). 이 것 은 올려 
태우기시에 파일체계의 모든 배정구조체를 주사하는 비용으로 상위블로크의 변화를 가동 
일지 에 기 록하는 휴지 시 간을 피 하자는데 있 다. 현재 계 획은 올려태우기의 주사를 피 하고 
상위 블로크의 변화를 기 록하자는데 있 다. 파일 체 계크기 와 전체 마당도 역 시 파일 체 계 의 
크기가 재정의될 때 동적으로 변화된다. 이 변화들은 기록되여야 한다. 

배정그를머리부 

매 개 파일 체 계자료부분一기 록권은 같은 크기 의(제 일 마지 막의것 을 제 외) 배 정그룹 
들로 분할된다. 이 크기는 파일체계가 생성될 때 선택된다. 크기는 전체 파일체계크기 
를 8 개 로 나눈 기 정 크기 로서 16MB-1GB 범 위 에 있게 된다. 중요한 최 소배 정그룹크기 의 
조건으로서 8개 의 배 정그롭들중에 는 최 소값이 존재하게 된다. 또한 배 정그룹크기 들에 
대한 배정과정에 둥그리기도 있을수 있다. 이것에 대한 구체적인 내용은 계속 연구하 
고 있다. 

파일체 계 를 배정그름으로 나누는 첫번째 리유는 파일체 계의 공간배 정 에서 병 렬화를 
촉진시 키 자는것 이 다. 배정정 보에 관한 잠금조작은 매 배정그롭당 따로따로 진행할수 있 
으며 이것으로 하여 성능이 개선되는데 특히 다중처리기환경에서 성능이 개선된다. 배정 
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그룹들은 읽기불가능한 환경에서도 그것들을 보다 쉽게 찾을수 있는 유일한 크기를 가진 
다. 만일 배정그롭들이 가변크기를 가진다면 매개 블로크는 다음 블로크가 어디에 있는 
가를 계산해 낼수 있도륵 읽기가능한 상태에 있든지 혹은 모든 배정그룹들의 주소를 포 
함하는 첨 수여 야 한다. 매 개 배 정그룹은 다음과 갈은것 들로 구성 된 다. 0바이 트위 치 의 상 
위 블로크(첫 번째 블로크는 파일 체 계 가 생 성 된후에 갱 신된 값을 취 한다.)，배 정 그롭머 리 부 
(상위블로크자료에 따라 첫번째 블로크에 일치시킨)，배정그롭머리부에 의하여 지적되는 
자료，파일체계메 타자료에서 모든《지 적 자》들은 배정그룹의 시 작과 관계 되는 32 bit 블 
로크번호 아래의것 을 제외 하고 64 bit 론리 적 블로크번호이 다. 다음 마당들은 배 정 그룹머 리 
부에 주어 진다. 

▼ 배 정 그룹머 리 부 매 지 크번 호(검 사용) 

• 배정그롭머리부 판본번호 

• 령 으로부터 출발하는 배정그룹번호 

• 비트매프배정도식이 리용될 때 자유블로크비트매프와 요약정보의 위치와 관계되 
는 블로크번호와 크기 ( lbsz ) 

• B 나무배정도식 이 리용될 때 B 나무 매 뿌리의 위 치(관계되는 블로크번호) 배정그 
롭머 리부의 론리적블로크로 한개 혹은 두개의 뿌리를 일치시 키기 위하여 선택할 
수도 있다. 

▲ 색 인마디 표를 포함하는《 색 인마디》의 위 치 (관계 되 는 블로크번 호)대 신 배 정 그룹 
의 다음것을 기억시킬수도 있다. 나무와 배정된 블로크와 색인마디들은 매 배정 
그롭별로 유지될수 있다. 

정 확성 을 위하여 배 정그룹머 리 부를 가동일 지 에 기 록해 야 할 필 요가 없는 여 유가동일 
지등록을 포함하여 변경 사항들이 기 록되 여 야 한다. 

한편 이 정보는 오직 상위블로크에만 존재하게 되며 여의 목적을 달성하는데는 충분하다. 

자료블로크자유목록 

자료블로크배정을 고찰하는데는 대체로 두가지 도식이 있다. 두 경우에 설계는 
핵 심 부대역 즉 완충기 에 아무러 한 정 보도 보존하지 않는다. 즉 모든 정 보는 디 스크로 
부터 읽어 들이고 또 디스크에 쓰며 모든 변경내용은 가동일지에 기록된다. 이 사실은 
매 배 정그를별로 기 억을 소비하는 설계 보다도 기 억리 용에 관해서 는 더 유연성 있는 
설계로 되게 한다. 

첫 도식에서 비트매프는 머리부정보와 비트매프자체를 포함한 배정그룹안의 모든 론 
리 적 블로크들을 포괄한다 . 비 트매 프는 배 정그를블로크로부터 얻 어 진 론리 적 블로크들의 
단순한 범위 이 다. 비트매 프는 파일체 계 가 확장(파일체 계의 가장 오랜 마지 막 배정그룹) 
되거 나 축소(파일체 계 의 제 일 최 근의 배정그롭)될 때 만 옮겨 진다. 비트매 프에서 비 트들 
은 자유블로크들의 모임이며 배 정블로크에 관해서 는 명 백하다. 주어 진 크기의 빈 범위를 
찾기 위하여，전체 비트매 프를 주사하는 현상을 피 하기 위하여 보충적 인 정 보가 기 억된 
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다. 매 개 비트매 프블로크에서 2의 루승 (2 KB ) 인 배정그롭에서의 매 개 가능한 범위 에 관 
하여 그 블로크로부터 시 작하여 2 KB -2 KB +1-1 의 크기 의 빈 범 위수를 보관한다. 《 블로 
크》는 파일체계의 론리적블로크들이다. 이 정보는 파일체계의 배정그룹과 론리적블로크 
의 크기 에 따라 가변크기 의 공간을 차지한다. 512 byte 블로크들과 1 GB 의 배 정그룹에 관한 
최 악의 경 우는 21 KB 이 다 . 4 KB 와 1 GB 의 배 정 그룹에 관하여 정 보의 크기 는 288 byte 이 다 
(4 KB 는 비트매프블로크크기로 주어 진다고 가정). 

매 개 계 수기입 구점 은 16 bit 이 다. 이 정 보는 주어 진 크기 에 관계 된 모든 입 구점 들 
이 함께 있 을수 있 게 순서화된 다. 이 입 구점 들은 요청 을 만족시 킬 수 있 게 충분하게 
큰 빈 범위 를 서술해 야 하는 비트매 프블로크를 탐색한다. 다음 비 트매 프블로크는 출발 
위치를 찾기 위하여 탐색한다. 이 도식을 약간 개조하여 매개 계수값이 단일한 비트 
매 프블로크안의 빈부분만을 포함하도록 제 한할수 있다. 이 도식 은 성 능에 의 존하여 
선택할수 있다. 

두번째 도식 에서 배정정 보는 B 나무의 쌍에 보존된다. 두개의 B 나무는 배정그룹안의 
모든 빈 범위에 대하여 그 쌍들을(시작자유블로크，자유블로크계수값)자료로서 포함한다. 
한개 B 나무는 시작자유블로크로 첨수화되며 다른 나무는 자유블로크계수값에 의하여 첨 
수화된다. 2차적 으로 열쇠를 일의 적 으로 생성하기 위하여 빈시 작블로크에 의하여 첨수화 
한다. 블로크배정 은 처음에 한개 B 나무를 람색하며 다음 캐쉬의 두 B 나무를 갱 신하며 
가동일 지 를 변경시 킨다. 일 단 가동일지입 구점 이 만들어 지 면 B 나무완충기 들은 실제 적으 
로 디 스크에 쓰기 위하여 개 방된 다. 캐 쉬 가 기 본적 으로 매타자료용의 LRU 도식 을 실 현 하 
고 있다고 가정하면 이것은 실제적으로 참조되고 있는 블로크들만이 기억에 존재한다는 
것 을 의 미한다. 

색인마디표 

XFS 설 계 자들은 전적 으로 색 인마디 를 배 정하는 전통적 인 방법 ( Solaris 의 UNIX 파일 체 
계인 UFS 와 같은)이 XFS 의 기본적인 설계목적과 배치된다는것을 알았다. 따라서 XFS 는 
색 인마디 를 요구대 로 작은 그름으로 배 정하는 도식 을 리용한다. 이 방법 은 색 인마디 들이 
단일한 가변크기범위로 기 억되거 나 혹은 색 인마디의 묶음을 지적하는 고수준첨수라는것 을 
말해 준다. 단일 범위 도식은 단순하지 만 파일체 계 가 토막화되 면 배정 이 실패할 우려가 있으 
므로 리용하지 않는다. 

첨수도식은 두가지 일반적 인 방법들중에서 어느 하나로 동작할수 있다. 즉 고정크기 
묶음의 자유색 인마디와 단일범위첨수방법 이 든가 혹은 정 규파일에서 리용되는것 처 럼 색 인 
마디《 파일》용의 B 나무(혹은 순서화된 범위지적 자)리용방법 으로 동작할수 있다. 여 기서 
는 후자의 방법 을 선 택하였 다. 매 배 정그롭의 머 리부는 색 인마디 공간과 색 인마디번 호를 
표시하는 B 나무의 뿌리 를 포함한다. B 나무는 배 정그룹을 위한 모든 색 인마디공간을 포 
함하는《 파일》을 표현하며 색 인마디번 호는 배 정그룹의 색 인마디번 호목록에 서 첫번째 
색 인마디 를 가리킨다. 색 인마디 자유목록상의 색 인마디 들은 색 인마디마당을 통하여 색 인 
마디번호로 련결된다. 색인마디들을 포함하는《파일》은 필요할 때 가능하면 선행배정 
에 대하여 확장된다. 임의의 다른 파일에서 진행되는바와 같이 색인마디들을 련속적으로 
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확장하려는 시도들이 있다. 하지만 색 인마디에 대한 직접 접근은 드물며 따라서 그의 실 
현이 그리 중요하지 않다는데 대하여 강조한다. 

색인마디표의 범위수를 작게 보존하는 실제적리유는 그것을 보다 넓게 표현할 
수 있는 B 나무를 보존하는데 있다. B 나무입구점은 색인마디범위의 첫번째 색인마 
디 에 대 한 색 인마디번 호의 낮은 32 bit 와 범 위 안에 서 의 색 인마디번 호(항상 한 블로크 
안의 색 인마디의 다중화된 번호), 관계 되는(배 정 그룹머 리 부와) 범위 시 작의 디 스크블 
로크번호를 포함한다. B 나무는 색인마디번호마당에 의하여 첨수화된다. 이것은 마 
당의 크기와 단위로만 bmap 함수에 리용된 B 나무와는 다르다. 그러나 알고리듬은 
같다. 자유목록리용에 비한 색 인마디비 트매 프의 리용상 문제 점 은 실제 로 색 인마디 
관리도식의 비교에서 서로 촉립적인 차원에 있다. 비트매프의 경우에 배정과 해제 
는 둘다 색인마디와 비트매프단어를 변경시킬것을 요구한다. 자유목록의 경우에 배 
정과 해제는 둘다 배정그를머리부와 색인마디의 변경을 요구한다. 자유목록의 경우 
는 자유목록의 지적자가 색인마디에 기억되기때문에 전체적으로는 더 적은 기억을 
요구한다. 리론적으로 자유목록의 경우는 비트매프가 서로 독립적으로 잠금이 수행 
될수있는 조각들로 나누어 질수 있기때문에 비트매프의 경우보다 더 적은 병렬처 
리를 요구한다. 사실상 이것은 그리 크지 않은 제한성이다. 왜냐하면 색인마디배 
정 은 매 개 배정그롭에서 병 렬적 으로 진행되기때문이 다. 비트매프의 경우는 배정 
그룹들이 서로 더 쉽게 가까와 지게 한다. 그러나 이것이 어느 정도 중요한가 하 
는것 은 명 백하지 않다 . 

자유목록대 신에 비 트매 프도식 을 사용함으로써 대 다수의 설 계 들은 색 인마디《 파 
일》에 걸 쳐 고유한 간격 으로 자유색 인마디 비 트매 프의 색 인마디 크기 화된 묶음들을 확산 
시 킨 다 . 실 례 로 색 인 마 디 크기 가 256 byte 이 면 256 X 8=2048의 색 인 마디 간격 을 가지 게 되 며 
색 인마디《 파일》의 변위 자료는 색 인마디 대 신 비 트매 프의 요소로 될 것 이 다. 따라서 배 정 
된 색 인마디 에 《 가까운》자유색 인마디 를 찾고 계 산하기 위하여 적 당한 비 트매 프블로크 
를읽고 배정된 색인마디비트위치의 근방을 찾아야 한다. 

다른 가능한 설계는 비트매프에 대한 범위의 독립적인 모임을 가지는것이다. 그 
러 면 우연적 인 크기 를 가지 는 비 트매 프들의 취 급에 대 하여 총체 적 으로 론의하여 야 한 
다. 비 트매 프를 작은 범위 즉 고정하거 나 가변적 인 크기 로 전환하는것 이 실 천적 이다. 
어떤 경 우에 지적한 비트매 프블로크를 찾는 일을 무시할수 없다고 하면 보다 많은 
yo 가 비트매프를 조종하는데 요구되며 자유목록에 비 한 단순한 비트매프의 부족점은 
대부분의 색인마디들이 배정되였을 때 정상상태에서 자유색인마디를 찾는 일이 보다 
더 어렵다는데 있다. 

색인마디번호 

색인마디는 파일체계 안의 매개 파일，등록부 등을 정의하는 정보들을 가지고 있다. 

매 색인마디는 색인마디 번호에 의 하여 혹은 첨수번호 ( inumber ) 에 의 하여 이름지 어 진다. 
전통적 인 UNIX 파일체계들에서 색 인마디는 전체 파일체계 에 걸쳐 순차적으로 번호화되 여 
있다. 그러한 체 계 들에는 매 개의 배정 혹은 실 린더그룹에 같은 수의 색 인마디 가 있으며 
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따라서 특정한 색 인마디 를 찾는데서 는 지 장이 없 다. XFS 의 매 개 배 정그룹에 는 가변길 이 
의 색 인마디들이 있으며 따라서 전통적 인 번호화도식은 첨수번호를 색 인마디의 디스크주 
소로 변환하기가 대단히 힘들다는것을 말해 준다. XFS 에서 색인마디번호는 두개의 비트 
마당으로 분할된 다. 보다 중요한 비 트마당은 배 정그롭번호이고 덜 중요한 비 트마당은 배 
정 그롭안의 색 인마디번호이다. 현재 까지 는 두개 의 비 트마당이 각각 32 bit 이 고 첨수번호 
는 64 bit 정 수이 다. 32 bit 정 수를 배 정그룹번호와 색 인마디번호로 나누는데서 어 려 운 문제 
는 파일체계가 너무 커질수 있는것이며 그것으로 인하여 일부 체계는 비트마당의 공간밖 
에서 실행되 게 된다. 현재 는 이 파일체 계의 설계 가 10년가량은 그대 로 리용되 리 라고 보 
고 디스크양식에서 이 공간을 쓰기로 하였다. 

자료와 속성블로크표현 

기록권안에서 파일의 주소공간을 디스크블로크로 넘기는것은 B 나무나 혹은 범위서 
술자에 의하여 실현된다. B 나무에서 나무의 매개 마디의 정보는 파일시작변위(론리적블 
로크에서)，기록권블로크시작번호, 범위 길이(론리적블로크)이다. 

B 나무는 다중준위 로 구성 된 다. 뿌리준위 를 제 외 하고 매 준위 에는 다중블로크들이 
있다. 잎이 없는 매개 블로크는 열쇠(파일의 시작변위값)와 다른 블로크에 대한 지적자 
를 포함한다. 

B 나무는 파일시작변위마당우에서 열쇠화된다. B 나무의 뿌리블로크는 색인마디에 기 
억되는데 이것은 뿌리블로크가 B 나무의 다른 블로크와 크기가 다르다는것을 의미하며 
파일 체 계 의 론리 적 블로크라는것 을 의 미한다. 지 적 자가 두개 의 열 쇠사이 에 놓일 때 지 적 
자에 의하여 지 적된 블로크의 자료(파일의 시 작변위)는 두 열쇠값사이 에 놓인다. 매 개 
블로크는 K 개 의 열쇠 와 K +1 개 의 지 적자를 가지 고 있 다. 

블로크가 완전히 차고 삽입이 요구될 때 두 조작들중 하나의 조작이 수행된다. 첫째 
로 회전이 시도되는데 회전은 린접하는 두 블로크들사이로 과잉마디를 이동시키려고 한 
다. 만일 블로크들이 차 있으면 블로크는 분할되고 정보의 절반은 새 블로크에 옮겨 지 
며 상위블로크는 한개대신 두개의 블로크를 지적한다. 다른한편 두개 블로크들은 세개의 
새 로운 블로크들을 생 성하면서 분할할수 있 다. 이 와 갈은 방법 으로 나무가 계 속 무성해 
진다. 수속은 뿌리에 도달할 때까지 혹은 상위블로크에 새로운 정보를 위한 자리가 마련 
될 때까지 재귀적으로 련속된다. 지우기조작은 본질적으로 남아 있는 블로크들이 충분히 
차 있는 정도에 따라 반대로 진행한다. 탐색조작은 나무에서 갈은 블로크번호라든가 혹 
은 가장 가까우면서 보다 낮은 객체를 찾으며 요청된 다음블로크가 존재하는가를 검사한 
다. 

범 위 서 술자의 경 우에 우리 는 배 렬 의 쌍 즉 범 위 크기 배 렬 ( lbsz , 32 bit ) 과 범 위 에 대 한 
지적 자배 렬 (64 bit 블로크번호)을 가지 고 있다. 만일 파일에 구멍 이 있으면 령범위지적 자에 
의하여 표시된다. 이 도식 은 작은 파일범위 에 의하여 전체 파일 에 리용될수 있다. 도식 
은 파일변위정 보가 루적크기 에 의하여 암시 적 으로 표시 되 기때 문에 특정한 블로크를 찾자 
면 배 렬전체 에 대 하여 선행탐색 을 요구하게 된다. 
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다른 방법으로서 파일변위는(다른것은 64 bit ) 기억되기도 하며 파일의 구멍에 대하여 
령지적 자를 무시할수도 있다. 이것은 2진람색 이 가능하다는것을 의미한다. 다른 말로 말 
하여 파일들이 구멍을 가지지 않는 표준경우에는 더 적은 사용자가 적합할수 있다는것을 
의 미한다. 이 정 보는 색 인마디등록부에 기 억된다. 이 정 보를 128 bit 아래 로 축소시 키 기 위 
하여 정보를 기억시킬수 있다. 실례로 범위에 해당하여 21 bit , 기록권블로크번호에 해당 
하여 52 bit , 파일블로크번호에 해당하여 55 bit 로 기억시킬수 있다. 

범위서술자조작은 그 표현이 색 인마디 에 일 치 하는 조건에서 는 사용가능하다. 사용할수 
없는 부분一기록권은 여러개의 고정크기조각으로 나누어 진다. 그 크기는 파일체계다중 
블로크크기 이며 mkfs 시 에 설정 되 고 상위블로크애 기 억되며 1 MB 정도 상대 적 으로 크다. 
따라서 이 부분一기 록권에 서 빈 공간은 단순한 비 트매 프에 의하여 표시 된 다. 비 트매 프는 
신뢰성이 있어야 하며 그 내용은 자료부분_기록권에 기억되는데 상위블로크가 그것을 
지 적한다. 배 정 속도를 더 높이 기 위하여 계 수기 에는 매 비 트모임 의 비 트매 프블로크번 호 
별로 보존된다. 이 계수값모임은 자료부분一기록권에 범위로써 보관되며 또한 상위블로 
크에 의하여 지 적된다. 

파일체계의 구조 

매 개 올려태우기된 파일체계 에는 파일체계 에 부속되는 정 보를 포함하거 나 지적하는 
핵심안 구조체(배정된)가 있다 (VFS 구조체). 이 구조체는 파일체계실현을 위한 전용자료인 
한개의 마당 cfs _ data 를 포함하고 있다. 이 마당은 몇가지 파일별 정보를 포함하는 한개 
의 구조체 ( XFS 용의 xfs _ mount ) 를 지 적한다. 

xfs _ mount 구조체는 다음의 정보를 포함한다. 

▼ VFS 구조체 에 대 한 거 물지 적 자 

• 기 록권의 자료대 역 에 대 한 블로크장치 용 Vnode 지 적 자 

• 기록권의 가동일지지 역 에 관한 블로크장치 용 Vvnode 지적 자 

• 파일체 계의 핵심안 뿌리색 인마디 에 대 한 지적 자 

• 배정몫에 대 한 몇 가지 마당 ; EFS 에는 기 발，색 인마디지적 자，크기 가 있다. 

• 체 계실현을 전환하여 자체 사용에 쓰기 위한 몇 가지 통계 적값 

• 상위블로크구조체의 복사 

▲ 배 정그룹당 한개 씩 의 짧은 구조체 배 렬 

배정대완충화 

림계자료구조체는 핵심안 배정대완충화에 대한 몇가지 질문을 가지고 있는데 여기에 
는 색 인마디，자료，색 인마디 배 정비 트매 프들이 포함된 다. 색 인마디 에 대 하여 색 인마디 를 
핵심안이나 핵심안 색인마디구조체의 고정크기풀에 캐쉬에 기억하는 우선권순위가 반드 
시 존재한다. 핵심안 색 인마디는 디스크상의 색 인마디뿐아니 라 지적자와 다른 정보도 포 
함한다. 이 색 인마디풀을 위한 배 정방법 은 검 증되 여 야 한다 . 색 인마디 에 관하여 다음의 
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의문은 파일의 디스크상의 구조를 표현하는 B 나무가 기억에 넣어 지는가 혹은 요구상으로 
완충기 에 기 억되는가 하는것 이 다. 대규모파일체 계를 지원하기 위하여 이 방법은 완충기를 
리 용할것 을 요구한다. 비 트매 프를 참조하는데 완충기 를 리용하도록 지 시하는 빈 자료블로 
크비트매프(혹은 B 나무)는 잠재적으로 매우 크다. 대규모파일체계용으로 배정된 기억에 
비트매프를 복사하는 기능을 사용자가 제공할수 있다고 볼수 없다. 색인마디배정구조체는 
크지 않지만 성능상 본질적손실이 없이 완충화될수 있다. 이러한 가정은 실천적으로 검증 
되여야 한다. 

XFS 의 유용성과 새 판본예고 

SGIXFS pre-release 0.9 는 Linux 2.4.0 에 대 하여 검 사수정 으로서 리 용할수 있 다. 또한 
이것은 RPM 의 모임으로서 그리고 Modified Red Hat 설 치자로서 리용할수도 있다. 다른 구 
획에서 Modified Red Hat 7.0 설치자는 뿌리구획이나 혹은 다른 구획에서 XFS 로 Red Hat 
7.0 체 계 를 설 치 하기 위 한 RedHat 7.0 설 치 매 체 를 가지 고 작업 한다. 

Linux 용 XFS 파일체계를 설치 하기전에 제 한목록，요구 그리고 이 발표판에 해 당한 특 
정한 지 령들에 관하여 Linux pre-release 0.9 의 XFS 를 일일 이 알아 보아야 한다. 

XFS 에 의한 작업 

Linux 워크스테이션이나 더 좋기는 봉사기상에서 XFS 로 작업하기 위하여서는 이를 
위한 구획과 파일체 계를 다시 생성하여 야 한다. ext2 파일체계 로부터 직접적 인 이행은 허 
용되지 않는다. XFS 로 작업 하기 위 하여서 는 3 가지 단계 : 구획설정，양식 화，올려태우기 
가 필요하다. 

구획설정 

새 로운 XFS 파일 체 계 를 생 성하기 위 하여 서 는 구획 이 필 요하다. 이 구획 은 새 로운 디 
스크로부터 만들수도 있고 이 미 존재하는 디 스크상의 설정 되지 않은 구획공간으로부터 도 
만들수 있 으며 현존구획 에 중복쓰기하여 설 정할수도 있다. 일 반적 으로 생 성하기 위하여 
서 는 fdisk 명 령 을 사용하여 “Linux Native(83)” 으로 구획 을 설정 할수도 있고 그 구획우 
에 서 XFS 파일 체 계 를 만들기 위하여 다음의 명 령 들을 리용할수도 있 다. 

XFS 파일체계생성 

어떤 다른 Linux 파일체계를 다음의 명령을 리용하여 생성했던것처럼 같은 방식으로 
새 로운 XFS 파일 체 계 를 생 성할수 있 다. 


mkfs -t xfs/dev/<devfile> 



여 기서 /(1야/<(1^미6>은 파일체 계 를 생성하려 고 하는 구획 이다. 이 과정 이 구획 에 현 
재 존재하는 임의의 파일체 계 를 파괴 한다는데 대 하여 강조한다. 

실례 로 2 차 SCSI 구동기의 세번째 구획 에 파일체 계 를 생성하기 위하여 다음의 명 령 
을 사용할수 있다. 

mkfs -t xfs/dev/sdb3 

요구될수 있는 중요한 한가지 선택항목은 “- f ” 인데 이 항목은 현재 구획에 이미 
파일체계가 존재할 때 새로운 파일체계의 생성을 강하게 요구하게 된다. 역시 여기서도 
구획상에 현재 있는 모든 자료는 파괴될것 이 라는것을 강조한다. 

mkfs -t xfs-f/dev/<devfile> 

보다 더 좋은 성능을 얻 기 위 하여서는 가동일지파일의 크기를 기정값 1, 200블로크 
로부터 8, 000블로크까지 증가시켜 야 한다. 

다음의 명 령은 파일체 계를 생성하는 방법 으로 실현할수 있다. 

mkfs -t xfs-1 iuternal, size=8000b 一 d name=/dev/c<devfile> 

다른 선 택 항목들은 XFS 파일 체 계 생 성 에 리 용할수 있 다. 

XFS 파일체계의 올려대우기 

다음으로 새로운 파일체계를 올려태우기해 보겠다. 

올려태우기명령은 다음과 갈다. 


mount 一 t xfs/dev/<devfile>/<mount_pt> 


여기서 / dev /< devfile > 은 파일체계를 포함하는 장치이며 /< mount _ pt > 는 파일체계를 
위 한 올려태우기점이다. XFS 는 실행기록파일체계 이므로 파일체계를 올려 태우기하기전 
에 완료되지 않은 임의의 거래에 관한 거래가동일지를 검사하며 새로운 파일체계로 이 
동시켜 준다. 
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부록 1 . 쏘프트웨어 RAID 의 리용방법 


이 리 용방법은 Linux 상태에서 쏘프트웨어 RAID 를 어떻게 사용하는가에 대하여 
서술한다. 이 체계는 쏘프트웨어 RAID 층의 특정한 판본 즉 Ingo Molnar 나다른 업체들 
에서 제작한 0.90RAID 층 등을 식별할수 있다. 여기서 설명하는 체계는 Linux2.4 에서 
표준으로 되 며 Linux2.2 핵 심 부에 서 리용할수 있는 판본이다. 0.90RAID 지 원관은 Linux 
2.0 과 Linux2.4 에 검 사수정 으로써 리 용할수 있 으며 여 러 가지 고찰결 과에 의 하면 이 미 
이 판본들에 서 리용하는 변경 된 RAID 지 원판보다 훨 씬 더 안정 하다는것 이 인정되 였 다. 

1 .요약 

2.0 과 2.1 핵심부의 표준으로 되고 있는것들중의 하나인 변경된 raid 층에 대하여 서술 
하기 위 하여 서 는 Linuxdoc. org 의 Linux Docameutation Project 로부터 리 용할수 있는 Linas 
Vepstas(linas@linas.org) 에서 HOWTO 를 찾아 보면 된다. 

이 참고서 를 위 한 홈싸 이 트는 http : //ostenfeld.dk/~jakob/software-RAID. HOWTO/ 이 며 
여기에는 우선 갱신된 판본들이 공개되여 있다. 

이 참고서는 RAID 개발자들과 여러 연구자들의 의견교환에 기초하여 씌여 졌는데 그 
것 을 쓰게 된 리유는 쏘프트웨 어 RAID 참고서 가 이 미 존재 한다고 해 도 변경 된 참고서 는 
표준 2.0, 2.4 핵심부에서 볼수 있는 변경된 형식의 쏘프트웨어 RAID 를 서술하고 있기때 
문이 다. 이 참고서는 보다 최근에 개 발된 새 형식 인 RAID 의 리용에 대 하여 서 술한다. 새 
형식의 RAID 는 변경된 형식의 RAID 에는 없는 수많은 특성을 가지고 있다. 

우리 가 2.0 이 나 2.4 핵 심부로 새 형 식의 RAID 를 리용하려 고 하면 핵심부를 위한 검사 
수정을 얻어야 하는데 ftp://ftp. [나라 코드 ]. Kernel.org/pub/Unux/daemons/raid/alpha 이라든가 혹 
은 http://people.redhat.com/mingo/ 로부터 보다 최신자료를 얻을수 있다. 표준 2.2 핵심부는 
이 참고서에서 서술한 새 형식의 RAID 를 직접 지원하지 못한다. 따라서 이러한 검사수 
정이 요구된다. 표준 2.0 과 2.2 핵심부의 변경된 형식인 RAID 는 오유가 있고 새 형식의 
RAID 프로그람에 주어 진 일부 중요한 특성들이 결여되였다. 

여 기 서 서 술하는것 처 럼 새 형 식 의 RAID 지 원 은 2.3 개 발판핵 심 부에 보충되 고 있 으며 
따라서 2.4Linux 핵 심 부에 로 주어 지 게 될 것 이 다. 그러 나 완성 되 기 까지 는 안정 판핵 심 부를 
수동으로 검 사수정하여 야 한다. 

2.2 에 서 RAID 를 지 원 하기 위하여 알란 목스 (Alan Cox) 가 발표한 _ac 핵 심 부를 사용하 
려고 해도 좋다. 이것들중의 많은것은 새 형식의 RAID 에 포함되여 있으며 핵심부를 자 
체 로 검 사수정하는 작업 으로부터 사용자의 안전을 보장할수 있 다. 

이 참고서에 대한 정보들중에서 그 일부는 대수롭지 않게 보이지만 raid 를 다 알고 
있으면 충분하다. 
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1.1. 권고 

RAID 가 많은 사람들에 게 안정하게 보이 더 라도 유익하게 동작하지 못할수도 있다. 
만일 자료와 공정을 모두 잃어 버렸다면 마치 자동차충돌사고와 같이 우연적사고로 하여 
어 쩔수 없는것 처 럼 우리 와 개 발자들의 잘못은 아니 라고 보아야 할것 이 다. 그리하여 
RAID 쏘프트웨어와 정보에 대 하여서는 사용자가 책 임져 야 한다. 이 런 점 에서는 쏘프트웨 
어나 정보도 모든 면에서 정확한것이라고 담보할수 없으며 어디에나 다 리용할수는 없다. 
때문에 이에 대하여서는 실험을 거쳐 야 보다 안전하게 쓸수 있다. RAID 쏘프트웨어와 관 
련된 안정성문제 가 아직 까지 는 제 기 되지 않았다는것을 강조해 둔다. 

1 .2 .요구 

이 참고서 는 사용자들이 raid0145 를 정 합시 키 는 검 사수정 과 raid 도구의 0.90 판본 
을 가진 2.2x 혹은 2.0x 핵심부의 신판을 사용하거나 2.3 핵심부의 후속판(판본 
>2.3.46) 을 사용하다가 마침 내 는 2.4 판을 사용하게 된다. 

검 사 수정 파 도구는 다같 이 ftp://ftp.fi.kernel.org/pub/linux/daemons/raid/alpha 그리 고 
일부 경우에는 http://peopel. redhat.com/mingo/ 에서 찾아 볼수 있 다. 

RAID 검사수정， raid 도구모임 그리 고 핵 심부는 가능한대 로 모두 밀접 하게 일치시켜 
야 한다. 

간혹 raid 검 사수정 들을 맨 마지 막핵 심 부에 리용할수 없 다면 변경 된 핵 심 부를 사용해 
도 된다. 

2. RAID 를 쓰는 리유 

여 러 가지 리유로 하여 RAID 를 리용할수 있 다. 그러한 리유로는 물리 적디 스크를 하 
나의 보다 큰《 가상》장치 로 결 합시키 는 능력 과 성 능의 향상，여 유도 등을 들수 있 다. 

2.1 . 전문절차 

Linux RAID 는 대 부분의 블로크장치 들에 서 작업 할수 있 다. 사용자가 IDE 를 쓰든지 
SCSI 장치를 쓰든지 또 그것들을 섞어 써도 아무런 일이 없다. 일부 사람들은 다소간의 
성 공률을 가지 고 망블로크장치 (Network Block Device : NBD) 를 리용하려 고도 한다. 

장치에서의 모선들도 속도가 충분히 빠르다는것을 담보할수 있다. 사용자는 매개 장 
치 가 lOMB/s 를 제 공할수 있고 모선이 40MB/S 만 유지 할수 있을 때 한대의 UW 모선에 14 
개 의 UW9-SCSI 구동기 를 련결 할수 없 다. 또한 사용자는 IDE 모선당 한개 의 장치만을 리 
용할수 있 다. 디 스크들을 주종방식 으로 실행 시키 는것 은 사실상 성 능상 견지 에서 보면 그 
닥 좋은 방법 이 못된 다. IDE 는 모선당 한개 이상의 장치 에 대 한 접 근에 서 는 실제 적 으로 
불리하다. 물론 보다 새 로운 주기판들은 모두 두개 의 IDE 모선을 가지 고 있 으며 따라서 
조종장치 를 더 주입하지 않고도 RAID 에 두개 의 디 스크를 설 치할수 있 다. 

RAID 층은 절대 적 으로 파일체 계층과 해 야 될 일 이 아무것도 없 다. 다른 블로크장치 
와 같이 RAID 우에 임의의 파일체 계를 설 치할수 있다. 
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2.2. 용 어 


용어 “ RAID ” 는 《 Linux 프로그람 RAID 》를 의 미 한다. 이 참고서 는 장치 RAID 에 
대하여서는 아무런 측면도 취급하지 않는다. 

설치할 때는 디스크의 수와 그것들의 치수를 고려해야 한다. 문자 자은 항상 배렬안 
에 서 능동디 스크의 수를 표시하는데 리 용된 다. 문자 S 는 특별 히 지 적하지 않는 한 배 렬 
의 제 일 작은 구동기 의 크기 를 의 미한다. 문자 모는 MB / S 로 표시 되 는 배 렬안에 서 한개 
디 스크의 성 능으로서 리 용된다. 리용할 때 우리 는 사실과는 맞지 않지 만 디 스크들의 속 
도는 항상 같다고 본다. 

용어 《 장치》와《 디 스크》는 갈은 객 체 를 의 미 하려 고 가정 된것 이 라는것 을 강조해 
둔다. 보통 RAID 장치 를 구성하는데 리용되 는 장치 들은 디 스크상의 구획이 며 전체 디 스크 
는 아니 다. 하지 만 한개 디스크상에 여 러개의 구획을 결합하는것은 보통 리해되지 않으며 
따라서 장치 라는 말과 디 스크라는 말은 곧《서 로 다른 디 스크상의 구획》을 의 미한다. 

2.3. RAID 의 준위 

여 기 에 서 는 Linux RAID 검 사수정 에 지 원되 는것 이 무엇 인 가에 대 하여 간단히 서 술한 
다. 이 정보들은 절대적이고 기본적인 RAID 정보이지만 Linux 실현준위에서 특별한것이 
무엇인가에 대한 몇가지 견해를 보충한다. 사용자가 RAID 에 대하여 알고 있다면 이 부 
분은 생 략한다. 이 제 이 미 론의하던 문제 에 대 하여 상기하자. 

현재 Linux 용 RAID 검사수정들은 다음과 같은 준위들을 지원한다. 

▼ 선형방식 

• 두개 이 상의 디 스크들은 한개 의 물리 적장치 와 결 합된 다. 따라서 디 스크들은 서 로 
《첨가》하면서 RAID 장치에 대한 쓰기는 디스크 0을 채우고 다음에 디스크 1을 
채우는 방법으로 차례차례 진행된다. 디스크들이 같은 크기를 가지지 않기때문에 
크기는 전혀 문제로 되지 않는다. 

• 이 준위 에는 여유도가 없다. 한개 디스크가 손상되면 사용자는 자기 자료의 거의 
대 다수를 잃어 버리게 될것 이 다. 하지만 사용자는 일부 자료를 회복시 킬수도 있다. 
왜냐하면 파일체계가 하나의 큰 련속적인 자료덩어리를 놓칠수도 있기때문이다. 

• 읽기와 쓰기성능은 단일읽기/쓰기 에서 증가하지 않는다. 그러 나 여 러명의 사용자 
가 장치 를 리용할 때 한 사용자는 첫 디 스크를 효과적 으로 사용할수 있지 만 다 
른 사용자는 두번째 디 스크에 존재할수 있게 어 떤 일을 발생 시킨 파일로 접 근할 
수 있다. 만일 무슨 일이 생기면 성능을 다시 알아 보아야 한다. 


• RAID -0 

• 《줄무늬》방식이라고도 부론다. 읽기와 쓰기가 장치들에 대하여 병렬로 진행되 
는것 을 제 외 하고는 선형방식 과 같다. 장치 들은 대 략적 으로 같은 크기 를 가져 야 
하며 모든 접근이 병렬로 진행되기때문에 동일하게 채워 진다. 만일 한개 장치가 
다른 장치보다 훨씬 크면 여 유공간이 여 전히 RAID 장치 에 서 리용되 지 만 RAID 장 
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치의 고속말단에 쓰기를 진행 하는 동안에는 큰 디스크하나에만 접근하게 될것 이 
다. 이 과정은 성능을 떨어 뜨린다. 

• 선형방식에서와 같이 이 준위에도 역시 여유도가 없다. 선형방식과는 달리 장치 
가 고장나면 자료를 구원할수 없다. 만약 설정된 RAID-0 으로부터 장치를 제거하 
면 RAID 장치는 한개의 련속적인 자료블로크를 잃지 않게 되며 장치전반에 작은 
구멍 들을 채 워 넣 게 된 다. e 2 fsck 는 아마 그러한 장치들로부터 많은것 을 회 복하지 
못하게 될것이다. 

• 장치상에서 읽기와 쓰기가 병렬로 진행되기때문에 읽기，쓰기성능이 높아 지므로 
RAID-0 을 사용한다. 디스크에 대한 처리가 충분히 빠르면 NXP MB/S 에 근사한 
높은 성능을 얻을수 있다. 


• RAID-1 

• 여유도를 가지고 있는 첫번째 방식이다. RAID-1 은 0 혹은 그이상의 예비디스크 
를 가지 고 있 는 두개 이 상의 디 스크상에 서 리용할수 있 다. 이 방식 은 다른 디 스크 
상에 한개 디 스크에 해 당한 정 확한 거 울정 보를 유지한다. 물론 디 스크들은 크기 
가 같아야 한다. 만일 한개의 디스크가 다른것보다 더 크면 RAID 장치는 제 일 작은 
크기를 가지게 될것이다. 

• N-1 개까지의 디스크가 제거될 때(혹은 파손될 때) 모든 자료는 그대로 보존되며 
예 비디스크를 리용할수 있으면 그리 고 체계 가(실례 로 SCSI 구동기 혹은 IDE 소편 
등) 폭주상태 에서도 살아 있으면 구동기오유검출후 거울의 재구성 을 예 비디스크 
상에서 즉시 시작할수 있다. 

• 쓰기성 능은 자료의 동일한 쓰기 가 배 렬안의 모든 디 스크에 대 하여 전송되 여 야 
하기때 문에 단일장치 에 서보다 좀 낮을수 있다. 읽 기 성 능은 보통 RAID 의 코드 
에 지 나치 게 간소화된 읽 기균형방법 을 적 용하는것 으로 하여 단일장치 에 서보다 
더 낮다. 그러 나 여 러 가지 보다 갱 신된 읽 기균형방법 들이 실 현되 였 으며 따라서 
이 방법 들을 Linux2.2 RAID 검 사수정 에 리 용할수 있 으며 표준 2.4 핵 심 부 RAID 
지원기능과 거의 갈다. 


• RAID-4 

이 RAID 준위 는 그리 자주 리용되 지 는 않는다. 이 준위 에서는 3 개 혹은 4 개 의 디 
스크를 리용할수 있 다. 정 보를 완전히 거 울화하지 않고 한개 디 스크에 기 우성 정 
보를 보존하며 RAID-0 에 서 와 같은 방법 으로 다른 디 스크에 자료를 기 억한다. 기 
우성 정 보를 기 록하기 위 하여 디 스크들이 예 약되 기 때 문에 배 렬 의 크기 는 (N-1) 邊 , 
S 로 된다. 여 기서 S 는 배 렬안의 제 일 작은 디 스크의 크기 이 다. RAID-1 에서 와 같 
이 디스크들은 같은 크기를 가져야 하거나 혹은 (N-l)XS 식의 드가 배렬의 가장 
작은 구동기의 크기로 되여야 한다. 

• 만일 한개 의 구동기 가 고장나면 모든 자료를 재구축하는데 기 우성 정보가 리 용된 
다. 또한 두개 장치 가 고장나면 모든 자료를 잃어 버리게 된다. 
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• 이 준위가 자주 리용되지 않는 리유는 기우성정보가 한개 디스크에 보존되기때문 
이다. 이 정보는 다른 디스크들중의 다른 어느 하나에 기록될 때마다 매번 갱신되 
여야 한다. 따라서 기우성디스크가 다른 디스크들보다 속도가 훨씬 뜨기때문에 
《병목》처럼 되여 버 린다. 하지 만 여러 개의 속도가 뜬 디 스크와 함께 속도가 빠 
른 디스크를 한개 가지게 되는 경우에 이 RAID 준위는 아주 쓸모가 있다. 


• RAID -5 

이 준위 에 RAID 가 많은 물리 적디 스크들을 결 합하려 고 할 때 제 일 쓸모 있는 
RAID 방식 으로 되 며 여 전히 일정한 여 유도를 가지 고 있 다. RAID -5 는 령 혹은 그 
이상의 예비디스크들을 가진 3개 혹은 그이상의 디스크들에 리용할수 있다. 
RAID -5 의 장치크기 는 RAID -4 와 같이 ( N - l ) XS 로 된다. RAID -5 와 RAID -4 의 
차이 는 RAID -4 에서 제 기된 《병 목》현상을 없애 기 위하여 포함된 디스크들속에 
기 우성 정보가 골고루 분배 된 다는데 있 다. 

• 만약 디스크들중의 하나가 고장났을 때 여전히 모든 자료가 그대로 보존되는것 
은 기우성정보가 우월하기때문이다. 예비디스크들을 리용할수 있으면 장치가 고 
장난후에 즉시 재구축을 시 작할수 있 다. 두개 디 스크가 동시 에 고장나면 모든 자 
료를 잃어 버리게 된다. RAID -5 는 한개 디스크고장은 회복할수 있으나 두개 이상에 
대 하여 서 는 불가능하다. 

▲ 읽기와 쓰기성능은 일반적으로 높아 지지만 어느 정도인가를 예측하기는 어 
렵 다. 

2.3.1. 예비디스크 

예 비디스크는 동작중에 있는 어 느 하나의 디 스크가 고장날 때 까지도 RAID 모임 에 포 
함되지 않는 디스크를 의미한다. 어느 한 장치 에 대 하여 고장이 검출되면 그 장치는 
《불량》으로 표시되며 리용가능한 첫번째 예비디스크를 리용하여 즉시 재구축을 시작 
할수 있다. 따라서 예 비디스크들은 물리적 으로 실현하기는 좀 어 렵지 만 RAID -5 체 계 에 
대하여 특별히 좋은 여유안전성을 추가적으로 제공한다. 모든 여유도가 여유디스크에 
의하여 보존되기때문에 이 방법은 고장난 장치가 있어도 아무때나 체계를 정상실행시 
킬수 있다. 사용자는 자기 의 체 계를 가지 고 디스크폭주를 회 복시 킬수 없 다. RAID 계 층 
은 장치적오유를 잘 조종해 야 하지 만 SCSI 구동기 들은 오유처 리 과정 에 정 지될 수도 있 
고 또 IDE 소편모임은 봉쇄되거나 기타 다른 일들도 생길수 있다. 

2.4. RAID 상에서의 교환기능 

교환성 능을 높이 기 위하여 RAID 를 리용할 근거 는 하나도 없 다. 핵 심 부는 자체 로 여 
러개의 디 스크상에서 교환작업 을 분할할수 있다. 

우수한 fstob 은 다음과 같다. 
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/ dev / sda 2 

Swap 

swap 

defaults ， pri=l 00 

/ dev / sdb 2 

swap 

swap 

defaults , pri=l 00 

/ dev / sdc 2 

swap 

swap 

defaults , pri=l 00 

/ dev / sdd 2 

swap 

swap 

defaults , pri=l 00 

/ dev / sde 2 

swap 

swap 

defaults , pri=l 00 

/ dev / sdf 2 

swap 

swap 

defaults , pri=l 00 

/ dev / sdg 2 

swap 

swap 

defaults , pri=l 00 


우의 설정은 기계 가 7개의 SCSI 구동기상에서 병 렬로 교환을 진행할수 있게 한다. 
이것은 오랜 기간 핵심부의 장점으로 되여 있었기때문에 RAID 에 관하여서는 아무런 필 
요도 없 다. 교환에 RAID 를 리용하는 다른 리유는 그것 의 높은 유용성 이다. 사용자가 만 
일 체 계를 기동할수 있게 실례 로 RAID -1 장치를 설정하면 체계는 디스크의 고장시 구조 
작업을 진행할수 있게 된다. 그러 나 체 계가 고장난 디스크상에서 교환되게 되 면 틀림없 
이 실패하게 될것이다. RAID -1 장치에서의 교환동작은 이 문제를 풀수 있게 한다. 교환 
이 RAID 장치 들우에 서 안정하겠는가에 대 하여 서 는 많이 론의되 여 왔다. 또한 이 문제 가 
핵심부의 서로 다른 측면들에 강하게 의존하기때문에 계속 론의중에 있다. 이러한 내용 
들로 하여 RAID 상에서의 교환동작은 배렬이 재구축될 때를 제외하고는 완전히 안정한것 
처럼 보인다(즉 새로운 디스크가 등급이 낮아 진 배렬에 삽입된후). 2.4 에 와서 이 문제 
는 아주 두렷하고도 긴절하게 제기되 였 다. 하지 만 그때 까지도 사용자는 안정성 을 만족시 
키거나 혹은 RAID 상에서 교환기능을 할수 없다는 결론이 엄어 질 때까지 자체로 동작상 
태 에서 체 계검사를 진행하여 야 하였다. 사용자는 자기의 RAID 장치의 파일체 계의 교환파 
일 (swap file ) 에 RAID 를 설 치 할수 있 다. 한편 RAID 장치 를 교환구획 으로 설정 할수도 있 다. 
평상시와 같이 RAID 장치는 곧 블로크장치 이 다. 

3. 장치적문제 

이 부분은 쏘프트웨어 RAID 를 실행시킬 때 제기되는 몇가지 관련부분들을 언급한다. 


3.1. ID 티 1 H 치구성 ( configuration ) 


IDE 디스크에서 RAID 를 실제적으로 실행시킬수 있으며 좋은 성능을 엄을수 있다. 사 
실 IDE 구동기 들과 조종장치 에 관한 문제 는 새 로운 RAID 체 계 를 설정할 때 IDE 에 관한 
문제를 고찰하여 야 한다. 

▼ 물리적안정성. 正®구동기 들은 전통적 으로 SCSI 구동기 들보다 공학적 으로 볼 때 
질 이 더 낮다. 오늘에 와서 도 IDE 구동기들에 대 한 품질담보는 1년이 지 만 SCSI 구 
동기에 대하여서는 3년〜5년이다. IDE 구동기들에 대한 매 정의들이 불중분하게 
주어 졌다고 말하기가 좀 공평하지 못하다 해도 일부 roE 구동기들이 류사한 
SCSI 구동기들보다 못하다는것을 알아야 한다. 그러나 일부 다른 구동기들은 
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SCSI 와 IDE 구동기 들과 동일 한 기 계 적 설 치 로 리용할수 있 다. 

• 자료통합성 이전에 IDE 는 IDE 모선에 보낸 자료가 디스크에 씌여 진 자료와 실제 
적으로 꼭 같다는것을 확인할만 한 방법 이 없었다. 이 원인은 전체적 인 기우성의 
결핍，검열결과가 같은것들때문이였다. 표준 Ultra-DMA 에서 IDE 구동기들은 현재 
구동기 가 접 수하는 자료에 대 하여 검 열합을 취 하며 따라서 자료가 손상되 는 일 
은 없어 지게 된 다. 

• 성능 여기서 IDE 성 능에 대 하여 상세 히 서 술하려 고 한다. 

IDE 구동기들은 속도가 빠르다 (12MB/S 혹은 그이상). 

IDE 는 SCSI 보다 CPU 휴지시간이 더 크다. 

한개 IDE 구동기 에 는 하나의 IDE 모선만을 리용할수 있 다. 따라서 종속디 스 

크들은 성능이 떨어 진다. 

▲ 오유회복 IDE 구동기는 보통 IDE 장치의 고장을 복구한다. RAID 층은 고장난 디스 
크에 대 하여 표식 을 달며 RAID 준위 1 이 나 그이상에서 실행 되 고 있으면 유지 상 
태 에서 해제될 때 까지 작업하게 된다. 正®모선당 한개 IDE 디 스크를 리용할수 있 
다는 사실은 아주 중요하다. 이 사실은 두 디스크를 사용하지 못하게 할뿐아니 
라 흔히 디 스크의 고장이 모선의 고장을 초래하며 따라서 모든 디 스크의 고장은 
그 모선상에 서 의 오유를 초래 하게 된 다. 고장안전 RAID 설 치 (RAID 준위 1, 4, 5) 에 
서 디스크의 고장은 조종할수 있지만 두개 디스크의 고장은(한 디스크의 고장으로 
하여 고장난 두 디스크) 배 렬을 파괴할수 있다. 또한 모선우에서 기본구동기 가 고 
장났을 때 종속구동기나 正®조종장치는 몹시 혼란되게 된다. 그러므로 한개 모선 
에 한개의 구동기를 설치하는것은 하나의 규칙 으로 된다. 이외 에도 값이 눅은 
pci 正®조종장치들이 있다. scsi 디스크보다 더 눅은 roE 디스크들을 사용하면서 
대 표적 인 체 계 들에도 추가할수 있 는 디 스크라는것 을 알게 되 였 다. IDE 는 큰 체 
계 로 구성할 때 케 블문제 가 중요하게 제 기된다. 사용자가 충분한 수의 PCI 슬로 
트들을 가지고 있다고 해도 체계에 8개이상의 디스크들을 정합시킬수 없었지만 
여전히 자료파손이 없이 실행되고 있다. 

3.2. 활성교환 

이 기 능은 어 떤 시 각에 Linux 핵 심 부목록에 서 의 활성문제 이 다. 구동기 의 활성교환기 능 
이 일부 범위들을 지원한다고 해도 여전히 사람이 쉽게 할수 있는것보다 못하다. 

3.2.1. IDE 구동기의 활성교환기능 

IDE 는 활성교환을 전혀 지 원하지 못한다. 그래 도 사용할수는 있으며 만일 사용자의 
IDE 구동기가 모둘로 콤파일되면 구동기에 재배치된후 그것을 다시 읽을수 있다. 그러나 
고장난 正®조종장치를 가지고 작업을 끝낼수도 있으나 그렇게 되면 해제된 체계에 구동 
기를 재배치하는데 걸린 시간보다 해제시간이 훨씬 더 길어 진다. 장치적으로 파괴될수 
있는 전기 적문제 를 제 외 하고 기 본문제 는 IDE 모선 이 디 스크가 교환된후에 다시 주사되 여 
야 한다는것 이 다. 현재의 IDE 구동기는 이 동작을 할수 없다. 만일 새로운 디스크가 변경 
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된 디 스크와 100%같은것 (무게，기 하학적크기 등)이 라면 재 주사를 하지 않고도 작업할수 
있지만 실지 로는 매우 위험 하다. 

3.2.2. SCSI 구동기의 활성교환기능 

표준 SCSI 장치 도 역 시 활성교환을 지 원 하지 못한다. 그러 나 이 장치 로 작업 은 할수 
있다. 사용자의 SCSI 구동기 가 모선의 재 주사，구동기 의 첨 가 및 삭제기 능을 지 원 하는 
활성교환장치로 리용할수 있다. 그러나 표준 SCSI 모선상에서 체계에 여전히 전원이 투 
입 된 상태 에 서 장치 의 플라그 (plug) 를 해 제 하는 동작은 하지 못할수 있 다. 하지 만 다시 
해보면 동작할수도 있 다. SCSI 층은 디 스크가 고장나면 원상태 로 회 복해 야 하지 만 모든 
SCSI 구동기는 아직 이 기능을 지원하지 못한다. 디스크가 해제될 때 SCSI 구동기가 정지 
되면 체계는 이 상태를 계속 유지할수 있으며 활성플라그는 사실상 흥미가 없게 된다. 

3.2.3. SCA 에 의한 활성교환기능 

SCA 를 리용하여 장치 를 활성플라그할수 있다. 하지 만 이 기 능을 수행하는 장치 가 
아직은 나오지 못하였다. 

만일 사용자가 이 기능을 실현해 보려고 한다면 SCSI 와 RAID 에 대 하여 파악해야 
한다. 

이 와 관련 하여 몇 가지 문제 점 들을 제 기한다. 

▼ linux/drivers/scsi/scsi.c 의 제거-단일-장치에 대하여 조사한다. 

▲ raidhotremove 와 raidhotadd 를 찾는다. 

모든 SCSI 구동기 들은 장치 의 추가/삭제기 능을 지 원 하지 못한다. 핵 심 부의 2.2 계 렬 에 
서 적어도 Adaptec2940 과 Symbios NCR53C8xx 구동기가 이 기능을 지원할것 같고 다른것 
들은 할수도 있고 못할수도 있다. 

4. RAID 설정 

4.1 . 일반적설정 

RAID 설정은 임의의 RAID 준위에 대하여 사용자에게 필요하다. 

▼ 핵심부 안정판 2.2 .x 핵 심 부 혹은 제 일 후판 2.0 .x 

• RAID 검사수정 보통 최 근의 핵 심 부에 리 용할수 있는 검 사수정 이 다 (2.4 핵 심 부를 얻 
는다면 검사수정들은 그안에 이미 들어 있으며 따라서 사용자는 검사수정에 대하 
여 생각하지 않아도 된다.). 

▲ RAID 至구 

이 프로그람들은 모두 ftp : //ftp.fi. kernel, org/pub/linux 에서 찾아 볼수 있 다. RAID 도 
구와 검 사수정 들은 /raid/alpha 등록부의 데 몬에 있 다. 핵 심 부는 핵 심 부등록부에 서 찾을수 
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있 다. 

핵심부를 검사수정 하고 사용자가 쓰러고 하는 준위 에 RAID 지원부를 포함시키기 위 
하여 배 치구성 을 진행한다. 그다음 RAID 도구의 압축을 해 제 하고 배 치구성 을 진행하며 
콤파일 하여 설 치한다. 

재 기 동할 때 사용자는 /proc/mdstat 라는 파일을 가지 고 있어 야 한다. 다음 RAID 모임 
에 포함시 키 려 고 하는 구획 을 생 성한다. 

4.2. 선형방식 

사용자가 곡 같은 크기가 아닌 두개 이상의 구획을 가지 고 있고 그것들을 서 로 추가 
하려 고 한다. 설치를 서술하기 위하여 /etc/raidtab 를 설정한다. 선형방식으로 두개의 디스 
크에 관하여 raidtab 를 설 치한다. 파일 형 식 은 다음과 같다. 

raiddev /dev/mdO 

raid-level linear 

nr-raid-disks 2 

chunk-size 32 

persistent-superblock 1 

/dev/sdb6 
0 

/dev/sdc5 



예비디스크들은 여기서 지원되지 않는다. 만일 한개의 디스크가 파괴되면 그것과 함 
께 배렬도 파괴된다. 따라서 예비디스크에 보존할 정보도 없다. 배렬을 생성하기 위하여 
다음의 명령을 수행한다. 


mkraid/dev/mdO 


이 조작은 배렬을 초기화하고 영구상위블로크를 기록하며 다음 배럴을 출발시킨다. 
이제 /proc/mdstat 를 보면 배렬이 실행되고 있다는것을 알수 있게 된다. 이제 사용자는 임 
의 의 다른 장치 에 서 생 성한것 과 갈은 파일체 계 를 생 성할수 있으며 그것 을 올려태 우기하 
고 사용자의 fstab 나 기타 위치에 그것을 포함시킨다. 

4.3. RAID -0 

RAID-0 은 대략적으로 같은 크기를 가진 장치들중에서 2 개이상의 장치들의 기억용량 
을 병 렬로 접 근시켜 결합시키는 방법 이 다. 배 치구성 을 서술하기 위하여 /etc/raidtab 파일을 
설정한다. 실례 를 아래 에 보여 주었다. 
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raiddev 


/dev/mdO 


0 

2 



chunk-size 


4 


device / dev/sdb6 

raid-disk 0 


device 


/ dev/sdc5 


여기에서도 역시 선형방식 에서와 같이 예 비디스크들을 지원하지 않는다. RAID -0 은 
여유도가 없으며 디스크가 파괴될 때 배럴도 파괴된다. 그러면 다시 배럴을 초기화하기 
위 하여 


mkraid/dev/mdO 


을 실 행한다. 이 조작은 상위블로크를 동기 화하며 raid 장치 를 시 동한다. 예 비 동작이 계 속 
진행 되 는가를 알아 보기 위하여 / proc / mdstat 를 실 행할수 있다. 그러 면 현재 사용자의 장치 
가 실 행 되 는가를 알수 있을것 이 다. / dev / mdO 은 양식 화，올려 태 우기 준비 가 된 다. 

4.4. RAID -1 

사용자가 대 략적 으로 같은 크기를 가지는 2개의 장치를 가지고 있으면서 서 로 거울로 
되게 하려고 할 경우가 있다. 실제적으로 사용자는 보다 많은 장치를 가지고 있으며 그 장 
치 를 보조대 기 ( stend - by ) 예 비 디 스크로 보존하려 고 하면 그것 은 능동디 스크들중의 하나가 정 
지될 때 자동적 으로 거 울의 한부분으로 될것 이 다. 그와 같은 / etc / raidtab 파일을 설정한다. 


raiddev/dev/mdO 

raid-level 1 

nr-raid-disks 2 

nr-spare-disks 0 
chunk-size 4 

persistent-saperblock 1 
device /dev/sdb 6 
0 

/dev/sdc5 
1 

만약 예 비디스크를 가지 고 있다면 그 장치들을 장치 정의부분의 끝에 추가할수 있다. 



320 



device /dev/sdd5 

spare-disk 0 

이것은 일 치 하게 nr - spare - disks 입구점들을 설정 한다는데 대 하여 강조해 둔다. 

이 제 RAID 를 초기 화하기 위하여 다음의 내 용을 설 정한다. 

1. 거 울이 구성 되 여 야 한다. 즉 두개 장치 의 내 용(장치 가 양식 화되 지 않았기때 문에 
아직 중요하지 않다.)이 동기화되여 야 한다. 

2. 거 울초기 화를 시 작하기 위하여 


mkraid/dev/mdO 
명령을 내보낸다. 

3. / proc / mdstat 파일을 검사한다. 이 조작은 / dev / mdO 장치 가 시동되 였으며 거울이 재 구 
성되고 있다는것 그리고 재구성의 완성에 대한 ETA 를 사용자에게 알린다. 

4. 재구성은 휴식중의 I/O 대역폭을 리용하여 진행한다. 이때 체계는 현재 디스크 
LED 가 빨갛게 표시되 였다 해도 여전히 뚜렷하게 응답하여 야 한다. 

5. 재 구성 과정 은 명 백하며 사용자는 현재 거 울이 재 구성상태 에 있 다고 해 도 장치 를 
실제 적 으로 리용할수 있 다. 

6. 재 구성 이 진행 되 는동안 장치 를 양식 화한다. 이 제 부터 는 작업할수 있다. 사용자는 
장치 를 올려태 우기할수 있 으며 재 구성 이 진행 되 는동안 그것 을 리용할수 있 다. 물 
론 재구성이 진행되는동안에 불량디스크가 중지되면 유감스러운 일로 된다. 

4.5. RAID -4 

주의 설치에 대한 다음의 내용은 어디까지나 추측에 불과하다는것을 지적해 둔다. 

사용자는 대략적으로 같은 크기의 3개 혹은 그이상의 장치들을 가지고 있으며 그중 
한개 장치 는 다른 장치보다 현저하게 속도가 빠르다. 또한 이 장치 들을 모두 몇 가지 여 
유정보를 보존하는 하나의 큰 장치로 결합하려고 한다. 결국 사용자는 예비디스크로서 
사용할 많은 장치 들을 가지 고 있 다. 이 경 우에 / etc / raidtab 파일 을 다음과 같이 설정한다. 


raiddev /dev/mdO 

raid-level 4 

nr-raid-disks 4 

nr-spare-disks 0 

persistent-superblock 1 
chunk-size 32 

device /dev/sdbl 

raid-disk 0 


device 


/dev/sdcl 
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device 


/dev/sddl 


raid-disk 2 

device /dev/sdel 

raid-disk 3 

만일 우리가 임의의 예 비디스크를 가지고 있다면 그것들을 raid - disk 정의 에 따라 여 
느때 와 같이 류사한 방법 으로 삽입할수 있 다. 

device /dev/sdfl 

spare-disk 0 

우리 가 가지 고 있는 디 스크배 렬 은 mkraid / dev / mdO 명 령 을 리 용하여 보통의 방법 으로 
초기화할수 있다. 

사용자는 장치 를 양식 화하기 전에 mke 2 fs 에 관한 특정 한 선택 항목들에 대 하여 알아야 
한다. 


4.6. RAID -5 

사용자는 대 략적으로 같은 크기를 가지는 3개 혹은 그이상의 장치들을 가지고 있으며 
그것들을 하나의 큰 장치로 결합한다고 하지만 자료의 안정성을 위하여 어느 정도의 여 유 
도를 유지 하려 고 한다. 한편 사용자는 다른 장치 가 고장나기 전에 배 렬안에 포함시키 지 않 
은 예 비디스크로 리용하기 위하여 여 러개의 장치들을 가지 고 있다. 

만일 사용자가 가장 작은 크기 S 를 가지는 자개의 장치를 가지고 있다면 전체 배렬 
의 크기 는 (N-l)XS 로 될것 이 다. 이 때 《 흘러 버 린》공간은 기 우성 정보(여 유도)에 리 용된 
다. 따라서 임의의 디스크가 고장나면 모든 자료가 그대로 유지된다. 하지만 두개의 디스 
크가 고장나면 모든 자료는 잃어 진다. 

이 를 위 하여 / etc / raidtab 파일 을 다음과 같이 설정 한다. 


raiddev / dev/mdO 

raid-level 5 

nr-raid-disks 7 


nr-spare-disks 0 

persistent-superblock 1 
parity-algorithm left-symmetric 
chunk-size 32 


device 

raid-disk 

device 


/dev/sda3 

0 

/ dev/sdbl 



device 

raid-disk 

device 

raid-disk 

device 

raid-disk 

device 

raid-disk 

device 

raid-disk 


/dev/sdcl 

2 

/dev/sddl 

3 

/ dev/sdel 

4 

/dev/sdf1 

5 

/dev/sdgl 

6 


만일 우리 가 임의의 예 비디스크를 가지 고 있다면 raid 디스크정의 에 따라 류사한 방 
법 으로 그것 들을 삽입할수 있 다. 


device /dev/sdhl 

spare-disk 0 


32KB 의 덩 어 리 (chunk) 크기는 이 크기를 리용하는 많은 일반목적파일체 계 에서 좋은 
기 정 값 (default) 으로 된다. 우에서 언급한 raidtab 가 리 용된 배 렬은 (7-1) X 6GB=36GB 를 
가진 장치 이 다. 이 장치 는 4KB 블로크크기 를 가지 는 ext2fs 파일 체 계 를 유지한다. 만일 사 
용자의 파일체계가 더 크거나 혹은 매우 큰 파일들을 가지고 있다면 배렬의 덩어리크기 
와 파일 체 계 의 블로크크기 를 둘다 더 크게 취 할수 있다. 충분히 이 야기되 였 으므로 이 제 
raidtab 를 설정하고 어떻게 동작하는가를 알아 보자. 


mkraid/dev/mdO 


이 명령을 실행시키고 어떤 일이 생기는가를 보자. 기대했던대로 디스크들은 배렬의 
재구성을 시작하면서 맹렬히 동작하기 시작한다. 어떤 동작이 계속되고 있는가를 알기 
위 하여 /proc/mdstat 를 찾아 볼수 있다. 만일 장치 가 성과적 으로 생성되면 이제 재구성 과 
정 이 시 작된다. 사용자의 배 렬은 이 재구성단계 가 완성될 때 까지 일관성을 유지 하지 못 
한다. 

그러나 배럴이 충분하게 동작하면 그것을 양식화할수 있고 재구성되고 있는 동안에 
도 리용할수 있다. 배렬을 양식화하기전에 mke2fs 의 특정한 선택사항들에 관한 부분을 
보는것이 좋다. 

사용자는 이제 RAID 장치가 실행중에 있을때 아무때나 그것을 정지시킬수 있고 혹 
은 다음의 명령 

raidstop/dev/mdO 이 나 혹은 raidstart/dev/mdO 을 리 용하여 정 지 시 킬 수도 있 고 재 출발시 
킬수도 있다. 
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4.7. 영구상위■로크 


이제 다시 앞으로 돌아 와서 raid 도구로 /etc/raidtab 파일을 읽고 배렬을 초기화한다. 
하지 만 이 조작은 /etc/raidtab 가 존재 하는 파일체 계 가 올려 태우기될것을 요구한다. 사용자 
가 RAID 로 기동하려고 하는 경우에는 이 방법 이 좋은 방법으로 되지 못한다. 

변경 된 방법 들은 RAID 장치 상에 서 파일 체 계 를 올려 태 우기 할 때 복잡한 문제 들을 야 
기 시 킨다. 그러한 파일체계 들은 여 느때 처 럼 /etc/fstab 파일에 설 치 되지 않고 init-scripts 부터 
올려태우기되 여 야 한다. 

영구상위블로크들은 이러한 문제점을 해결할수 있게 한다. 배렬이 /etc/raidtab 파일에 
서 영구상위블로크선택항목으로 초기화될 때 특정한 상위블로크가 배렬에 포함되는 모든 
디스크들의 앞머 리에 씌여 진다. 이 과정은 핵심부로 하여금 늘 리용할수 없는 일부 배 
치구성파일로부터 읽기를 진행할 대신에 포함된 디스크들로부터 직접 RAID 장치의 배치 
구성 을 진 행할수 있 게 한다. 

그러 나 사용자는 배 렬의 다음번 재 구성 을 위하여 그런 요구를 제 기할수도 있기때 문 
에 /etc/raidtab 파일의 일관성이 여전히 유지되여야 한다. 

영구상위블로크는 체계가 기동한 상태에서 RAID 장치들을 자동검출할 때 그 관리기 
로 된 다. 이 내 용은 자동검 출부분에 서 설 명한다. 

4.8. 덩어리의 크기 

덩어리크기는 설명해야 할 가치가 있는 내용이다. 사용자는 디스크들의 모임에 대하 
여 완전한 의미에서 병렬쓰기를 진행할수 없다. 만약 사용자가 두개의 디스크를 가지고 
있으면서 한개 바이트를 쓰려고 한다면 매 개 디스크에 4개의 비트를 써 야 할것 이 다. 실 
제적으로 매개 두번째 비트는 디스크 0에 가야 하고 다른것들은 디스크 1에 가야 한다. 
장치로써는 이 과정을 지원하지 못한다. 대신 우리는 임의로 덩어리크기를 선택할수 있 
는데 이 덩 어 리 크기 는 장치 에 쓸수 있는 자료의 제 일 작은《 원자적》모임 으로 정 의한다. 
4KB 의 덩어리크기를 16KB 에 쓰는 조작은 두개 디스크를 가지는 RAID-0 의 경우에 첫 
4KB 덩 어 리와 세번째 4KB 덩 어 리를 첫번째 디 스크에 쓰며 두번째와 네번째 덩 어 리는 두 
번째 디 스크에 기 록하게 한다. 따라서 대 량쓰기 에서는 될수록 큰 덩 어 리들을 리용하면 
휴지시 간을 감소시 킬 수 있 으며 따라서 작은 파일 들을 가지 고 있는 배 렬 들은 보다 작은 
덩 어 리크기로부터 보다 큰 리 익을 얻을수 있다. 

▼ 덩 어 리크기들은 선형방식을 포함하여 모든 RAID 준위들에서 정의되 여 야 한다. 

• 성 능을 확고히 높이기 위하여 값들만이 아니 라 배 렬우에 적재된 파일체계의 블 
로크크기를 가지고도 실험을 해야 한다. 

▲ /etc/raidtab 에서 덩어리크기에 대한 인수는 KB 단위로 정의되는데 《4》는 4KB 를 
의 미 한다. 


324 



4.8.1. RAID-0 


자료는 배렬안의 디스크들에 《거의》병렬로 씌여 진다. 덩어리크기를 4 KB 로 정의 
하고 3개의 디스크배렬에 16 KB 를 쓰면 RAID 체계는 디스크 0, 디스크 1，디스크 2에 병 
렬로 4 KB 를 쓰고 나머지 4 KB 는 디스크 0에 쓴다. 

32 KB 로 덩 어 리크기를 정의하는것 이 대 다수의 배 렬들에서 적 합한 출발점 으로 되 고 
있다. 하지만 이 현저한 값은 포함된 구동기의 수，거기 에 설정된 파일체계의 내 용，기 타 
다른 요소들에 크게 의 존하게 된다. 그러 므로 이 값이 더 좋은 성 능을 엄 으려 면 실험해 
보아야 한다. 

4.8.2. RAID-1 

쓰기과정에서는 덩어리의 크기가 배렬에 아무런 영향도 주지 않는다. 왜냐하면 모 
든 자료가 아무런 장애도 없이 써지기때문이다. 그러나 읽기에 대해서는 덩어리크기 
가 포함되는 디스크들로부터 얼마만한 자료를 직 렬로 읽는가를 정의한다. 배 렬안의 
모든 능동디스크들이 같은 정보를 포함하기때문에 읽기는 RAID -0 에서와 같이 병렬로 
진행 될 수 있다. 

4.8.3. RAID-4 

쓰기 가 RAID -4 배 렬에서 진행될 때 기 우성비 트는 기 우성디 스크상에서 도 갱 신되 여 야 
한다. 이때 덩 어 리크기는 기우성블로크들의 크기 이 다. 만일 한개 바이트가 RAID -4 배 렬에 
기 록되면 덩 어 리크기 바이 트들은 N -1 개의 디스크들로부터 읽 을수 있으며 기 우성정 보가 
계산되 고 덩 어 리크기바이트들이 기우성디스크에 기록된다. 

덩어리크기는 RAID -0 에서와 꼭같은 방법으로 읽기성능에 영향을 준다. 


4.8.4. RAID-5 

RAID -5 에서 덩어리크기는 RAID -4 와 완전히 곡같은 의미를 가지고 있다. RAID -5 에 
적합한 덩어리크기는 128 KB 이지만 이 크기로 실험을 해보려는것도 좋다. 

또한 mk 2 fs 에 관한 특정한 선택 항목에 서 이 부분을 고찰해 보아야 한다. 이 내 용이 
RAID -5 의 성능에 영향을 준다. 

4.9. mke2fs 의 선택항목들 

mke 2 fs 로 RAID -4 와 RAID -5 를 양식 화할 때 리 용할수 있는 특정 한 선택 항목이 있 다. 
-R stride ^ nn 항목은 RAID 장치 상에 서 지 능적 인 방법 으로 mke 2 fs 를 ext 2 정 의 형 자료구조와 
다르게 배 치할수 있 게 한다. 

덩 어 리 크기 가 32 KB 이 면 32 KB 의 련속적 인 자료가 디 스크우에 존재 하게 된다. 우리 가 
4 KB 의 블로크크기를 가지고 ext 2 파일체계를 구성하려고 한다면 한개배렬덩어리에 8개의 
파일체 계블로크를 구성할수 있을것 이 다. 우리는 파일체계 를 생성할 때 이 정 보를 mk 2 fs 
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편의프로그람에 넘겨 줄수 있다. 

mke2fs-b 4096 -R stride=8 /dev/mdO 

RAID -{4,5} 의 성능은 엄격히 이 선택항목의 영향을 받는다. 이때 분할걸음선택항목 
이 다른 RAID 준위들에 어떤 영향을 줄것 인가에 대 하여서는 확신하지 못하고 있다. 

ext 2 fs 블로크크기 는 파일 체 계 의 성 능에 큰 영 향을 준다. 사용자는 항상 파일 체 계안에 
매 우 작은 파일들을 대 량적 으로 기 억시키지 않는 한 수백메 가바이트이상의 임 의의 파일 
체계에 대해서는 4 KB 의 블로크크기를 사용해야 한다. 

4.1 0. 자동검출 

자동검 출은 기 동시 에 일 반 구획 검 출이 끝난 다음 즉시 핵 심 부에 의하여 RAID 장치 들이 
자동적으로 인식되게 한다. 이 조작은 몇가지 조건들을 요구한다. 

1. 핵심부안에서 자동검출지원기능이 필요하다. 이것을 검사해야 한다. 

2. 영구상위블로크를 리용하여 RAID 장치 들을 생성해 야 한다. 

3. RAID 에 리 용된 구획 형 들은 Oxro ( fdisk 를 리용하여 형 을 “ fd ” 로 설정)로 설정해 
야 한다. 


주의 : 사용자의 RAID 가 구획형이 발견되기전에 실행되지 않는다는것을 알아야 한다. 
장치를 정지시키기 위하여 raidstop / dev/mdO 를 리용할수 있다. 

만일 사용자가 우로부터 1，2, 3을 설정하면 자동검 출이 설정 될것 이 다. 재 기동하고 
체계가 동작되기 시작할 때 / proc/mdstat 로 RAID 가 실행 중에 있다는것을 통보하여야 한다. 
기동중에 사용자는 아래와 류사한 통보문을 볼수 있다. 


oct 22 00:51:59 malthe kernel : SCSI device sdg : hdwrsector=512 
bytes, Sectors=12657717 [6180MB] [6.2GB] 
oct 22 00:51:59 malthe kernel : partition check : 
oct 22 00:51:59 malthe kernel : sda: sdal sda2 sda3 sda4 

oct 22 00:51:59 malthe kernel : sdb: sdbl sdb2 

oct 22 00:51:59 malthe kernel : sdc: sdcl sdc2 

oct 22 00:51:59 malthe kernel : sdd: sddl sdd2 

oct 22 00:51:59 malthe kernel : sde : sdel sde2 

oct 22 00:51:59 malthe kernel : sdf : sdf 1 sdf2 

oct 22 00:51:59 malthe kernel : sdg: sdgl sdg2 

oct 22 00:51:59 malthe kernel : autodetecting RAID arrays 
oct 22 00:51:59 malthe kernel : (read) sdbl ， s sb offset : 619872| 
oct 22 00:51:59 malthe kernel : bind 

oct 22 00:51:59 malthe kernel : (read) sdcl ， s sb offset : 619872| 
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oct 22 00:51:59 malthe kernel 

oct 22 00:51:59 malthe kernel 

oct 22 00:51:59 malthe kernel 

oct 22 00:51:59 malthe kernel 

oct 22 00:51:59 malthe kernel 

oct 22 00:51:59 malthe kernel 

oct 22 00:51:59 malthe kernel 

oct 22 00:51:59 malthe kernel 

oct 22 00:51:59 malthe kernel 

oct 22 00:51:59 malthe kernel : autorunning mdO 

oct 22 00:51:59 malthe kernel : running 

oct 22 00:51:59 malthe kernel : now! 

oct 22 00:51:59 malthe kernel : md: mdO : raid array is not clean¬ 
starting background reconstruction 


bind 

(read) sddl ， s sb offset : 619872| 
bind 

(read) sdel ， s sb offset : 619872| 
bind 

(read) sdfl ， s sb offset : 6205376 
bind 

(read) sdgl ， s sb offset : 6205376 
bind 


이 통보문은 명 백하게 전원이 꺼지지 않은 RAID-5 의 자동검출과정 에 출력되 는 통보 
문이 다(실례 로 체계 가 폭주된 경우). 재구성은 자동적 으로 시동된다. 이 장치의 올려태우 
기조작은 재구성이 명백하고 모든 자료의 일관성이 보장되므로 안정성 이 완전히 보장된 
다(기 우성 정 보망은 일 관성 이 없 지 만 장치 가 고장나기 전 에 는 필 요없 다.). 

자동출발한 장치들은 전원차단시 역시 자동적으로 정지된다. 

init scripts 는 걱 정하지 않아도 된 다. 이 제 다른 명 령 으로서 /der/md 를 사용하자. 


/dev/sd or / dev/hd devices 


사용자는 임의의 raidstart/raidstop 명령에 관한 init-scripts 를 보고싶을수 있는데 이 정 
보들은 흔히 표준 RedHat init scripts 에서 찾아 볼수 있다. 이 내용은 변경된 형식의 RAID 
에 리용되며 자동검출을 지원하는 새 형식의 RAID 에는 없다. 

4.1 1 . RAID 상에서의 기동 

RAID 장치상에서 뿌리파일체계를 올려태우기하는 체계를 설정하는데는 여러가지 방 
법 이 있다. 어떤 때는 RedHatLinux 6.1 의 그라프설 치프로그람만이 RAID 장치를 직 접적으 
로 설정하게 한다. 이 렇게 하고 싶을 때 많은 사람들은 체 계의 기능변경을 하여 야 할것 
처럼 인식되며 가능하다. 가장 최근의 사무용 lilo 배포판(판본 21) 은 RAID 를 조종하지 못 
하며 따라서 핵 심 부는 기동시 RAID 장치 로부터 적재 될수 없 다. 사용자가 이 판본을 리용 
하면 /boot 파일체계는 비 RAID 장치에 존재하여야 한다. 체계가 기동한다고 해도 그것을 
담보하는 방법 은 사용자의 RAID 의 모든 구동기 에 류사한 /boot 구획 이 생 성하는것 이 다. 
즉 BIOS 가 어 떤 장치 실례 로 리용가능한 첫번째 구동기 로부터 자료를 적재하게 하는 방 
법 이 다. 이 조작은 사용체 계안의 고장난 디 스크로 기 동하지 말것 을 요구한다. 

redHat 6.1 에서 1 : lilo 21 에 대 한 검사수정은 RAID-1 에서 조종하거 나 기동할수 있 
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다. 이 검사수정이 그 어떤 다른 순위에서 동작하지 않는다는것을 알아 두어야 한다. 
RAID-1 (거 울디 스크)이 유일 체 계 지 원되 는 RAID 준위 이 다. 

이 검사수정 (lilo.raidl) 은 임의의 reahat 거울상의 dist/redhat-6.1/SRPMS/SRPMS/lilo- 
0.21-1.0.src.rpm 에 서 찾을수 있 다. LILO 의 검 사수정 판본은 lilo.conf 에 서 boot=/dev/mdO 을 
받아 들이게 되며 매 디스크를 기동가능한 거울로 만들수 있게 한다. 

사용자의 체계가 항상 기동할수 있다는것을 담보하는 또 다른 방법은 모든 설치를 
진행 하는 기 동용플로피 디 스크를 만드는것 이 다. /boot 파일 체 계 에 존재 하는 디 스크가 고장난 
디스크라면 언제 나 플로피 디스크로부터 기동할수 있다. 

4.1 2. RAID 상의 뿌리파일체계 

RAID 상에서 기동하는 체계를 준비하기 위하여서는 RAID 장치상에 뿌리파일체계 (/) 가 
올려태 우기 되 여 야 한다. 이 목적 을 달성 하기 위한 두가지 방법 을 아래 에 제 공한다. 현행 
배포판(적어도 알려 진것들중에서)에는 RAID 장치에 설치하는 지원기능이 없기때문에 이 
방법 들은 표준구획 상에 서 설 치 한다고 가정 하고 RAID 가 아닌 장치 의 뿌리파일 체 계 를 새 
로운 RAID 장치로 옳긴다. 

4.12.1. 조작 1 

이 방법은 사용자가 체계를 설치할수 있는 예비디스크를 가지고 있다고 가정하는데 
이 디 스크는 배 치 구성 을 진행 할 RAID 장치 가 아니 다. 

▼ 첫째 로 예 비디스크에 표준체 계를 설치한다. 

• 운영 하려 고 계 획 하는 핵 심 부， raid- 검 사수정，도구들을 선택 하고 새 로운 RAID- 인 
식핵 심부로 체 계를 기동한다. RAID- 지 원프로그람이 핵 심부안에 있는가，모둘로서 
적재되지 않았는가를 확인한다. 

• 다음 배 치 구성 을 진행 하고 뿌리 파일 체 계 로 쓰러 고 하는 RAID 를 생 성 한다. 이 조 
작은 이 책의 다른 부분에서 서술되고 있는것처 럼 표준적 인 절차로 된다. 

• 매 개 조작들이 원 만히 되 였 다는것 과 새 RAID 가 기 동상태 로 준비되 였 는가를 알 
아 보기 위 하여 체 계 를 재 기 동시 킨 다. 

• 파일 체 계 를 새 로운 디 스크배 렬 에 배 치 하고 (mke2fs 를 리용하여 ) 그것 을 
mnt/newroot 아래 에 올려 태 우기 한다. 

• 사용자의 현재 뿌리파일체계(예비 디스크) 의 내용을 새 뿌리파일체계(배렬)에 복사 
한다. 이 과정 을 실 현 하는 방법 들에는 여 러 가지 가 있 는데 우의것 은 그것 들중의 
한가지 방법이다. 


cd/ 

find, -xdev/cpio -pm/mnt/newroot 

• 뿌리 파일 체 계 에 정 확한 장치 를 리 용하기 위 하여 /mnt/newroot/etc/fsstab 파일 을 변 
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경시켜야 한다. 

• 현행 /boot 파일 체 계 의 올려태 우기 를 해 제 하고 /mnt/newroot/root 에 기 동장치 를 대 
신 올려태 우기한다. 

• 정 확한 장치 를 지 적 하기 위 하여 /mnt/newroot/etc/lilo.conf 를 갱 신한다. 기 동장치 는 
여전히 정 규디스크여 야 하지만 뿌리장치는 새 로운 RAID 를 지적해 야 한다. 다 
되 면 오유없 이 완성 하는 liloT7mnt/newroot 를 실 행 한다. 

▲ 체계가 재기동하며 모든 상태가 예견했던대로 나타난다. 사용자가 이 조작을 
IDE 디 스크들을 가지 고 실행할 때 는 모든 디스크들이 《자동검 출》형 식 으로 되 였 
는가와 BIOS 에 통보하였는가를 알아야 하며 따라서 BIOS 는 부정확한 디스크를 
리용해도 체계를 기동시킬수 있게 될것이다. 

4.12.2. 조작 2 

이 방법은 사용자가 부정 확한 디스크 지 령을 가지고 있는 raidtools.patch 를 사용하 
는 경우에 적용하는 방법 이 다. 이 방법은 2.2.10 과 그 이후의 모든 핵심부에 관한 도 
구/검 사수정 에 해 당한다. 사용자는 이 방법 을 RAID 1 준위 와 그 웃준위 들에서 만 리용 
할수 있다. 

기본착상은 RAID 에 틀린것(고장난것)으로 표기된 디스크에 체계를 설치하고 그다음 
하급 (degraded) 방식 으로 운영 할 RAID 에 체 계를 복사하며 마지 막에 하급방식 이 아닌 상태 
에서 RAID 를 운영하던 변경된 설 치판을 지우고 RAID 가 더 이상 설 치디스크가 없이 도 운 
영되게 하는것이다. 

▼ 우선 표준체 계 를 한개 디 스크(후에 RAID 부분으로 될)에 설 치한다. 이 디 스크(혹 
은 구획)가 제 일 작은 디스크가 아니 라는 점 이 중요하다. 만일 제 일 작은 디스크 
이면 그것을 RAID 에 추가하는것은 불가능하다. 

• 다음 핵 심 부，검 사수정，도구 등을 선택 한다. 사용자가 요구하는 RAID 지 원기 능을 
가지며 핵심부로 콤파일된 새로운 핵심부로 체계를 기동한다. 

• raidtab 파일 의 고장난 디 스크로서 현행 뿌리장치 를 가진 RAID 를 설 치한다. 고장난 
디스크를 raidtab 안의 첫 번째 디스크로서 배치 하지 말아야 한다. 이렇게 되면 
RAID 로서 출발하는데 일정한 문제가 생길수 있다. RAID 를 생성하고 거기에 파 
일체계를 놓는다. 

• 재기동하고 RAID 가 정확히 동작하는가를 알아 본다. 

• 앞부분에서 서술한것처럼 체계를 복사하고 뿌리장치로 RAID 를 리용할수 있게 
체 계 의 배 치 구성 을 다시 한다. 

• 체계가 RAID 로부터 성과적으로 기동하면 고장난 디스크를 포함하는 raidtab 파일 
을 표준 raid 디 스크로 변경할수 있 다. 

▲ 사용자는 하급상태가 아닌 RAID 로부터 기동할수 있는 체계를 가질수 있게 
되였다. 
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4.1 3. RAID 에서 체계기동파일만들기 

뿌리파일체 계 를 올려태 우기할수 있는 핵 심 부에 서 뿌리파일체 계 가 존재 하는 장치 에 
대한 모든 지원기능이 핵심부에 있어야 한다. 

따라서 RAID 장치 에 뿌리파일 체 계 를 올려태 우기하기 위 하여 서 는 핵 심 부가 RAID 지 원 
기능을 가지고 있어 야 한다. 핵심부가 RAID 장치를 알고 있다는것을 확인하는 표준적 인 
방법 은 자체안에 콤파일 된 모든 필 요한 RAID 지 원 기 능을 가진 핵 심 부를 를파일하는것 이 
다. RAID 지 원기 능을 적 재 가능한 모둘로서가 아니 라 핵 심 부로 를파일 한다는데 대 하여 주 
의 를 돌려 야 한다. 핵 심 부는 뿌리 파일 체 계 가 올려 태 우기 되 기 전에 는 모둘을(뿌리 파일 체 계 
로부터 ) 적 재할수 없 다. 

하지만 raidHat-6.0 의 새로운 형식의 RAID 지원기능을 모둘로서 가지고 있는 핵심부 
로 배포되기 때문에 여기서 표준 RaidHat-6.0 핵심부를 어떻게 리 용하는가에 대하여 서술 
한다. 

4.13.1. RAID 으 I 모듈로서의 기동 

사용자는 이 조작을 수행 하기 위하여 LILO 에 RAM 디스크를 사용할수 있게 지 령을 
주어 야 한다. 

뿌리 구획 을 올려태 우기하기 위하여 필요한 모든 핵 심 부모둘을 포함하는 RAM 디 스크 
를 생 성할수 있도록 mkinitrd 명 령 을 리용한다. 이 조작은 다음과 같이 실 행할수 있 다. 

Mkinitrd - with: 

실례로 

mkinitrd - with=raid5 raid-ramdisk2.2.5-22 

이 조작은 뿌리장치 를 올려태 우기할 때 리용하기 위한 핵 심 부에 대 하여 정 의된 
RAID 모둘이 기동시에 존재하는가를 확인하게 될것이다. 

4.1 4. 우 I 험 

실 행중에 있 는 RAID 의 구성 부분인 디 스크의 구획 은 다시 설 정 할수 없 다. 사용자가 
RAID 의 한 부분인 어느 한 디스크의 구획들을 교체하여 야 한다면 우선 배 렬의 동작을 
중지 시 키 고 다음에 구획의 재 설정 을 진행하여 야 한다. 

하나의 모선우에 여 러개의 디스크를 설정하는것은 어 렵지 않다. 

표준고속-광대역 SCSI 모선은 현재 많은 디 스크들이 단독으로 실 행할수 있는것 보다 
좀 더 작은 10MB/S 의 속도를 유지하고 있다. 모선상에 이러한 디스크 6 개를 설치하는것 
은 물론 사용자가 기대했던 정도의 성능을 보장하지 못한다. SCSI 모선들이 디스크들을 
서 로 극단적 으로 가깝게 배 치하였 을 때 보다 많은 SCSI 조종장치 들이 사용자에 게 여 유 
있는 성능을 제공할수도 있다. 한개의 조종장치에서 두개의 디스크를 실행시킬 대신에 
두개의 변경된 SCSI 디스크를 가진 두개의 2940 형을 사용해서는 성능을 향상시킬수 없 
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을것 이 다. 

만약 사용자가 영구상위블로크의 선택항목을 잊었을 때는 배렬이 정지된 이후에 그 
것을 다시 출발시킬수 없을수도 있다. 

이때는 raidtab 에 정 확하게 설정된 선택 항목으로 배 렬을 다시 생성 한다. 

만일 한 디 스크가 제 거 되 였 거 나 혹은 삽입 된 후에 RAID-5 가 재 구성 에 서 실 패 하면 
그것은 raidtab 안의 디스크들의 순차성 때문일 수도 있 다. 이때는 첫 번째 “device，"” 과 
“raid-disk” 의 쌍을 raidtab 파일의 배 렬서술자 밑바닥으로 옮겨 본다. 

우리 가 Linux 핵 심부에서 볼수 있는 대부분의 《오유보고》는 정 확한 판본의 raid 도구 
들로 정 확한 RAID- 검 사수정 을 사용하기 위하여 무엇 인가 해보다가 실패한 사람들이 제 
기 한 내 용이 다. 사용자가 0.90RAID 를 리용하고 있 으면 그에 해 당한 raidtools 를 리용하고 
있는가를 확인해 야 한다. 

5. 시 험 

사용자가 고장견딤 성 을 얻 기 위하여 RAID 를 사용하려 고 하면 그것 이 실지 적 으로 동 
작하는가를 알기 위하여 설정을 시험해 볼 필요도 있을수 있다. 그러면 디스크의 결함을 
어떻게 모의할수 있는가를 보자. 구동기 가 고장일 때 어떤 일 이 발생 하는가에 대 하여 누 
구도 알수 없 다. 고장은 모선자체 일수도 있고 전기적원인에 의하여 생길수도 있 다. 구동 
기 는 SCSL0DE 계 층에 대 한 읽 기/쓰기오유에 대 하여 통보할수도 있 는데 이 때 SCSFIDE 는 
RAID 계층이 이 상태를 깨끗하게 조종할수 있게 한다. 

5.1 . 구동기오유의 모의 

구동기오유에 대하여 모의하려고 할 때 먼저 구동기의 플라그를 해제한다. 이것은 전 
원을 끄는 방법으로도 할수 있다. 사용자가 일반적인 개수보다 더 적은 디스크로써 자료 
를 회 복할수 있겠는가를 검 사하는데 흥미 를 가진다면 그런 관점 은 무모하고 어리 석 다. 
체계를 개방하고 디스크의 플라그를 해제하여 다시 기동한다. 

체 계의 가동일지 를 들여 다 보고 raid 의 동작여부를 알아 보기 위 해 /proc/mdstat 를 고 
찰한다. 사용자는 자기의 디스크배렬의 디스크오유를 되살릴수 있도록 RAK)-{1, 4, 5} 의 운 
영 상태 에 있 어 야 한다는것 을 상기해 야 한다. 

선형방식 이 나 혹은 RAID-0 방식 은 장치 가 부정 확하면 완전한 실패 로 된다. 사용자가 
디 스크를 다시 련결 할 때(물론 전원을 끈 상태 에 서 )는 raidhotadd 명 령 으로 RAID 에 다시 
새 장치를 추가할수 있다. 

5.2. 자료손상모의 

RAID (장치 나 혹은 프로그람)는 만일 디 스크에 대 한 쓰기 가 오유를 귀 환시키 지 않으 
면 쓰기 가 성 공하였 다고 가정한다. 따라서 사용자의 디 스크가 오유를 귀 환시키 지 않았는 
데 자료가 흐트러 지면 그 자료는 파괴된것으로 인정된다. 이러한 경우는 물론 생길것 같 
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지 않지만 가능하며 이것은 파일체계가 손상된 결과라고 볼수 있다. 

RAID 는 매체 에서의 자료손상에 대 하여 보호하는 문제 는 제 기하지 않고 있으며 할수 
도 없다. 그러므로 RAID 체 계 가 오유를 어 떻게 조종하는가를 알아 보기 위하여 일부러 자 
료를 손상시키는것 역시 리치에 맞지 않는다. 

RAID 계 층이 자료손상에 대 하여 찾을수 없 다는것 은 거 의 명 백하며 게 다가 RAID 장치 
에 있는 파일체계도 손상될수 있다. 이것은 연구과정에 제기된 방법의 하나이다. 

RAID 는 자료통합성을 담보하지 못하며 항상 디스크가 죽으면 자료를 보존할수 있게 
한다(즉 같거 나 높은 RAID 준위 에서). 

6.재 구축 

사용자가 이 참고서 의 마지 막부분을 읽 어 보면 하급방식 의 RAID 의 재구축이 어 떤 
내용을 포함하는가에 대하여 잘 알게 될것이다. 

▼ 체계의 전원정지 

• 고장난 디스크의 교체 

• 다시 체계의 전원투입 

• 배렬에 디스크를 삽입하기 위하여 raidhotadd 기능인 /dev/mdx/dev/sdx 를 리용 

▲ 자동재구축이 실행되는 일정한 시 간 기 다린다. 

이 과정은 보통 사용자에게 별다른 일이 없고 또 여유 있는 디스크보다 더 많 
은 디 스크가 고장난것 으로 하여 RAID 를 리용할수 있는 조건에서 는 일 반적 으로 실 
행 된다. 그러한 현상은 같은 모선상에 많은 디 스크들이 존재하며 한개 디 스크가 폭 
주된 디스크의 모선을 점유할 때 발생한다. 그러나 다른 디스크들은 모선이 내려 지 
기때 문에 RAID 계 층에 도달되 지 못할수 있 으며 이 때 그것 들은 오유가 생 긴것 으로 
표식 된 다. 

사용자가 한개 예 비디스크로 쓸수 있는 RAID -5 에 관하여 두개 혹은 그이상의 디 
스크들을 풀어 놓는 조작은 치명적오유를 발생시킬수 있다. 

6.1 . 다중디스크오유의 회복 

절차는 다음과 같다. 

▼ 조종장치가 정지되고 동시에 두개 디스크들의 련결이 해제된다. 

• 한개 SCSI 모선의 모든 디 스크들은 한개 디 스크가 정지되 면 더 이상 도달될수 없다. 

▲ 케블이 풀려 진다. 


간단히 말하여 한번에 여러개의 디스크들에서 림시적고장이 생기는 경우가 있다. 



후에 RAID 상위블로크들은 동기에서 제외되며 사용자는 더이상 RAID 배렬을 초기화 
할수 없다. 다른 하나의 것은 mkraid 에 의 하여 상위 블로크를 재 쓰기 한다. 만일 이것이 장 
치들과 동작이 진행되지 않는 초기디스크들의 순서를 일치시키지 못하면 이 조작을 실현 
하기 위 하여 현재 까지 의 /etc/raidtab 를 가지 고 있 어 야 할것 이 다. 

배 럴을 시 작하여 생성 된 체 계 가동일지들을 찾아 보고 매 개 상위블로크에 해 당한 사 
건계수값을 파악한다. 

만일 사용자가 고장난 디 스크가 없 이 mkraid 를 실 행하면 회복스레드가 즉시 얻 어 지 
고 기 우성 블로크의 재구축이 시 작된 다. 

7.성능 

이 부분은 프로그람 RAID 를 리 용하는 실 체 계 들로부터 제 기 되 는 많은 성 능평 가기 준 
을 포함한다. 성 능평 가는 시 험프로그람에 의하여 수행 되 며 모든 시 간동안에 파일 에 관하 
여 두번 혹은 콤퓨터 의 물리 적 RAM 의 크기 에 따라 그이상 진행할수도 있 다. 여 기 에서 의 
성능평 가는 하나의 대 규모단일파일에 관하여 입 력과 출력의 대 역폭만을 측정한다. 알아 
야 할 문제가 하나 있는데 만일 큰 읽기/쓰기에 대하여 최대 I/O 처 리능력 이 주어 지면 
거기에 관심을 돌리게 된다. 그러나 이러한 수값들은 우리에게 배렬이 새로운 풀이나 
Web 봉사기 등에 리용될 때 어떤 성능이 발휘되겠는가에 대하여서는 극히 적은 정보만을 
제공해 준다. 

항상 성능평가기준값들이 《합성》프로그람의 실행결과라는데 대하여 알아야 한다. 

특정 한 콤퓨터 에 대 한 평 가시 험 결과를 제 시 한다. 

▼ 2 중 pentium pro 150MHZ 

• 256MB RAM(60MHZ EDO) 

• 3 개의 IBM UltraStar 9ES 4.5GB,SCSI U2W 

• Adaptee 2940 U2W 

• 하나의 IBM UltraStar 9ES 4.5GB,SCSI UW 

• Adaotec 2940 UW 

▲ RAID patch 를 가진 kernel 2.2.7 

3 개의 U2W 디스크는 U2W 조종장치 에서 분리되며 UW 디스크는 UW 조종장치 에서 분 
리된 다. 

RAID 를 사용하거나 혹은 사용하지 않으면서 이 체계의 SCSI 모선을 거처 30MB/S 이 
상의 속도를 얻는것은 불가능한것처럼 보인다. 추측에 의하면 이 체계가 낡았기때문에 
기억대역폭이 흡수되고 따라서 SCSI 조종장치를 거처 보내지므로 속도에 제한이 있다는 
것 이 다. 
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블로크크기는 둘다 실제적인 차이가 있다. 


다울화된 분할걸음》이거나 혹은 두개의 RAID -0 배렬로 구성된 RA 
I 크기 는 RAID -1 배 렬 과 두개 의 RAID -0 배 렬덩 어 리 크기 이 다. 

로 되 였 다 하더 라도 덩 어 리 크기 가 다르면 검 사하기 가 곤난하다. 


덩 어 리 크기 

블로크크기 

읽 기 ( KB / s ) 

쓰기 ( KB / s ) 

32 K 

1 K 

13753 

11580 

32 K 

4 K 

23432 

22249 


900 MB 였다. 왜냐하면 포함된 4개의 구획들의 매개가 500 MB 。 
람의 설치에 1 GB 대역을 주지 않기때문이다(두개의 1000 MB 
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부록 3. Loopback 뿌리파일체계의 리용방법 

이 리용방법 은 구획 을 재 구성 하지 않고 DOS 구획 으로부터 실 행 할수 있는 Linux 고유파 
일체계방식의 설치판을 생성하는데 Linux loopback 장치를 어떻게 리용하는가를 설명하고 
있 다. 이 와 곡 갈은 기 술들중에 서 다른 사용방법 들도 역 시 토론된다. 

1 •요약 

1.1. 저작권 

Loopback Root Filesystem 참 고 서 Copyright © 1998-99 Andrew M.Bishop (amb @ 
gedanken.demon.co.uk) 

이 문서 는 개 방문서 이 다. 사용자는 무료쏘프트웨 어 재 단에 의하여 출판된 GNU 일 반공 
개사용허가권의 협정하에 누구나 이것을 재배포할수 있으며 또한 변경시킬수 있다. 더 
구체적으로 알기 위해서는 GNU GPL 을 참조하면 된다. 

1 .2. 개정력사 

판본 1.0.0 초기판본 (1998.6) 

관본 1.0.1-1.0.3 약간의 변경과 핵심부관본변경 OS 형 등 (1998-1999.6) 

판본 1.1 저 작권과 재허 가권보충 (1999.9) 

2. Loopback 장치와 Ramdisk 으 I 원리 

먼저 뿌리 장치 토서 loopback 를 설정 하는데 리 용된 몇 가지 일 반적 원 리 를 서 술한다. 

2.1. Loopback 장치 

Linux 에 서 Loopback 장치 는 어 떤 다른 매 체 장치 로 사용할수 있 는 가상장치 이 다. 표준 
매체장치의 실례로는 /dev/hdal, /dev/hda2. /dev/sdal 과 같은 하드디스크구획들이거나 혹은 
플로피 디스크 /dev/fdo 등과 같은 전체 디스크들을 들수 있다. 

이 것 들은 모두 파일 이 나 등록부구조를 보존하는데 리용할수 있는 장치 들이 다. 이 장 
치 들은 요구되 는 파일 체 계 (ext2fs, msdos, ntfs 등)로 양식 화될 수 있으며 그다음 올려태 우 
기될수 있다. Loopback 파일체계는 다른 파일체계의 파일과 완전한 장치로서 련결된다. 또 
한 이 체계는 우에서 목록으로 보여 준 임의의 다른 장치와 같이 양식화될수 있으며 올 
려태 우기 될수 있 다. 

이 를 위 하여 /dev/loopO 혹은 /dev/loopl 이 라고 부르는 장치 가 파일 과 련관되 며 이 새 
토운 가상적장치 가 올려태 우기 된 다. 
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2.2. Ramdisk 장치 

Linux 에 서 는 또한 파일 체 계 로서 올려태 우기 된 다른 형 의 가상장치 들을 가질수 있는 
데 이 것 이 바로 Ramdisk 장치 이 다. 

이 경 우에 장치 는 어 떤 물리 적장치 로 간주되 지 않고 그 목적과는 별개 로 설정한 기 
억의 한 부분이다. 배정된 기억은 디스크밖으로는 절대로 교환되지 않지만 디스크캐쉬에 
는 남아 있게 된다. ramdisk 는 임의의 순간에 ramdisk 장치 /dev/ramO 혹은 /dev/raml 에 써 
넣 는 방법 으로 생 성할수 있 다. 다음 이 디 스크는 loopback 장치 에 서 와 같은 방법 으로 양식 
화되 고 올려 태 우기 될 수 있 다. ramdisk 가 기 동하는데 리 용될 때 (보통 Linux 설 치 디 스크나 
혹은 회 복디 스크) 디 스크이 메 지가(단일 파일 로서 디 스크의 전체 내 용) 압축된 형 식 으로 기 
동플로피디 스크상에 기 억 될수 있 다. 

이 조작은 기동시 핵 심 부에 의하여 자동적 으로 인식 되 며 그것 이 올려태 우기되 기 전에 
압축이 해제되 여 ramdisk 에 적재된다. 

2.3. 초기 Ramdisk 장치 

Linux 에 서 초기 ramdisk 장치 는 뿌리파일 체 계 로 loopback 장치 를 사용할수 있 게 할 요 
구로부터 나온 하나의 중요한 기술이 다. 

초기 ramdisk 는 파일체계이 메지 에 리용될 때 기억에 복사되고 올려 태우기 되며 따라 
서 거기에 있는 파일들에 접근이 가능하게 된다. 이 ramdisk 우의 프로그람이 (/linuxrc 라고 
부론다.) 실행되 여 그것 이 완료되 면 다른 장치 가 뿌리파일체 계 로서 올려태우기된다. 그렇 
지 만 변경된 ramdisk 는 여전히 존재 하며 /initrd 등록부에 올려 태우기되거 나 /dev/initrd 장치 
를거쳐 리용될수 있다. 표준기동순서는 지적된 뿌리구획으로부터 기동하며 실행을 계속 
한다. 초기 ramdisk 선택항목을 리용하여 뿌리구획은 기본기동순서가 시작되기전에 변경가 
능하게 된다. 

2.4. 뿌리파일체계 

뿌리파일체계는 기동후에 /라는 등록부로 나타날수 있도록 제일 처음에 올려태우기 
되는 장치이다. 모든 파일들을 포함하고 있다는 사실로부터 그 파일들이 있는 뿌리파일 
체계에는 복잡성이 많다. rc 스크맆트에 대한 기동이 실행될 때 이 프로그람들은 /etc/rc.d 
에 있는 파일 이 거 나 /etc/init 프로그람의 판본에 따라 / etc/rc?.d 에 있는 파일일수도 있 다. 
그 근거 는 초기 ramdisk 가 마지 막뿌리구획 이 기 동시 에 적재 된 구획 과 득 같아 지 지 않도 
록 하는데 리용될 수 있 으므로 쓸모 있 다는데 있 다. 

2.5. Unux 기동순서 

초기 ramdisk 가 기동시 에 어떻게 동작하는가를 보기 위 하여 사건의 순서를 아래 에 
보여 준다. 

1. 핵심부가 기억에 적재되는데 이 조작은 LILO 나 혹은 LOAEHNG 에 의 하여 수행된 
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다. 이 과정의 실행은 Loading •••통보문을 통해 알수 있다. 

2. ramdisk 이메지 는 기억에 적재 되며 이것은 다시 LILO 혹은 LOAEONG 에 의 하여 수 
행된다. 사용자는 이 과정을 역시 Loading •••통보문을 통하여 볼수 있다. 

3. 명 령 행 선택 항목의 문장론적 해 석 과 뿌리 장치 로서 ramdisk 의 설 정 을 포함하는 핵 심 
부의 초기화가 진행된다. 

4. 초기 ramdisk 상에서 /linuxrc 프로그람이 실행된다. 

5. 뿌리장치 가 핵 심 부파라메터 에 정 의 된것 으로 변경 된 다. 

6. 사용자배 치 구성기동조작이 차례 로 수행 될 /etc/init 프로그람이 실행된다. 

3. Loopback 뿌리장치의 생성방법 

먼 저 일 반적 원 리 를 설 명 하고 lookback 장치 를 생 성 하는 방법 을 서 술한다. 

3.1 . 요 구 

loopback 뿌리 장치를 생성하기 위하여 여 러 가지 요구가 제 기된다. 

▼ 작업용 Linux 체계 

▲ 목적 DOS 구획에 큰 파일을 복사하는 방법 

가장 중요한것은 설치된 Linux 체계에 대한 접근이다. 접근이 중요한것은 loop 장치가 
Linux 하에서만 생성될수 있기때문이다. 이것은 아무것도 없는데서 동작하는 체계를 기동 
할수 없다는것을 의미한다. 사용할 Linux 체계에 대한 요구는 사용자가 체계우에 핵심부 
를 를파일해 야 한다는것 이 다. 

일단 loopback 장치가 생성되면 생성된 파일은 한개의 큰 파일로 된다. 80MB 파일을 
사용했을 때 X 말단을 리용하는데는 충분하지 만 다른 프로그람을 더 사용하려 고 하면 그 
리 충분하지 못하다. 이 파일은 DOS 구획우에 복사되여야 하며 망이라든지 혹은 여러가 
지 플로피디스크들을 리용할수 있게 되여야 한다. 

사용자에 게 요구되는 프로그람들에는 다음과 같은것들이 포함될수 있다. 

▼ LOADLIN 판본 1.6 혹은 그이상 

• loopback 장치 를 지 원하는 올려태 우기관본 

• 요구되는 선택항목을 지원하는 핵심부관본 

▲ 모든 프로그람들은 최근의 Linux 설치프로그람에 대하여 표준으로 되여야 한다. 

3.2. Unux 핵심부생성 

Linux 판본 2.0.31 을 리 용하여 loopback2 장치 를 생 성 하였 다. 다른 판본들도 동작할수 
있지만 그것들은 적어도 다음과 같은 선택항목들을 가지고 있어야 한다. 

리용하는데 필 요한 핵 심 부선택 항목들은 다음과 갈다. 
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▼ RAM 디 스크지원 (CONFIG_BLK_DEV_RAM) 

• 초기 RAM 디스크 (ini 仕 d) 지원 (CONFIG_BLK_DEV_INITRD) 

• Loop 장치 지 원 (CONFIG_BLK_DEV_LOOP_ 

• fat 파일 체 계 지 원 (CONFIG_FAT_FS) 

▲ MS-DOS 파 일 체 계 지 원 (CONFIG_MSDOS_FS) 

첫 두개 항목은 RAM 디 스크장치 자체의 초기 RAM 디스크에 대 한것 이 다. 

다음의 것 은 loopback 파일체 계 항목이 다. 마지 막두개 는 MSDOS 파일체 계지 원을 위 한것 
인데 이것은 DOS 구획 을 올려태우기하는데 필요하다. 

사용자가 모둘을 요구하며 또 그것이 가능하다고 해도 제일 쉬운 방법은 모둘없이 
핵 심 부를 콤파일 하는것 이 다. 

사용자가 가지 고 있는 핵심부의 판본에 따라 핵심부검사수정을 적용해 야 한다. 이것 
들은 loopback 장치 를 뿌리파일체 계 로 사용할수 있게 하는 아주 간단한것 들이 다. 

▼ 2.0.0 이전의 핵심부판본 ; 이것들에 대한 정보는 없다. 

• 핵심부판본 2.0.0-2.0.34 ; 사용자는 아래 에 보여 준것처 럼 2.0.x 핵심부에 대하여 
핵심부검사수정을 적용하여 야 한다. 

• 핵 심 부판본 2.0.35-2.0.X ; 핵 심 부검 사수정 이 요구되 지 않는다. 

• 핵심부판본 2.1 .x ; 2.0 .x 혹은 2.2 .x 에 대 하여 핵심부검사수정을 적용해 야 한다. 

• 핵심부판본 2.2.0-2.2.10 ; 아래 에 보여 준것 처 럼 2.2. x 핵 심부에 관하여 핵 심부검 
사수정을 적용해 야 한다. 

▲ 핵심부판본 2.3.x ; 아래 에 보여 준것처 럼 2.2.x 핵심부에 핵심부검사수정을 적용 
해야 한다. 

2.0.x 핵심부에 대하여 /init/main.c 는 아래의 변경된 판본에 보여 준것처럼 한개의 행 
을 보충할것을 요구한다. 

static void parse_root_dev(char*line) 

{ 

int base=0; 

static struct dev_name_struct{ 


const char*name; 
const int num; 



； loop” , 0x0700}, 

； hda” , 0x0300}, 

sonycd” , 0x1800 }, 


{NULL, 0} 
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2.2. x 핵 심부에서 Ainit / main . c 는 아래 에 보여 준것 처 럼 3개 행 을 보충할것을 요구한다. 
“ loop ” ， 0 x 0700 과 그옆에 있는것들을 포함하는 행이 보충된것들이다. 
static struct dev_name_struct{ 
const char *name; 
const int num; 

}root_dev_names [] — initdata={ 

#ifdef CONFIG_ROOT_NFS 
{ “ nfs” , OxOOff 
#endif 

#ifdef CONFIG_BLK_DEV_LOOP 
{ “ loop” , 0x0700}, 

#endif 

#ifdef CONFIG_BLK_DEV_IDE 
{ “ hda” , 0x0300}, 

{ “ ddv” ,DDV_MAJOR « 8}, 

#endif 

{NULL, 0} 

}； 


일 단 핵 심 부가 배 치 구성 을 완료하면 zlmage 파일 을 생 성 하기 위 하여 를파일 하여 야 한 
다. 이 파일 은 틈파일 될 때 arch / i 386/ boot / zImage 에 존재 하게 된 다. 

3.3. 초기 Ramdisk 장치생성 

초기 ram 디스크는 출발로부터 시작하여 loopback 장치로 아주 쉽게 생성된다. 사 
용자는 이 조작을 뿌리에 관하여 진행하게 된다. 사용자가 실행해야 할 명령들을 
아래에 보여 준다. 이 명령들은 뿌리의 홈등록부 (/ root ) 로부터 실행되는것으로 가정 
한다. 


mkdir / root/initrd 

dd if=/dev/zero of=initrd.img bs=lk count=1024 
mke2f s -i 1024 -b 1024 -m 5 -F -v initrd. img 
mount initrd. img/root/initrd -t ext2 -o loop 
cd initrd 
[create the files] 
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cd. . 

umount /root/initrd 
gzip -c -9 initrd.img>initrdgz.img 


이것을 실행하기 위한 단계들을 아래에 제시한다. 

1. 초기 ram 디 스크를 위 한 올려 태 우기 위 치 를 생 성 한다(빈등록부로서). 

2. 요구되는 크기의 빈파일을 생성한다. 여 기서 는 1024 KB 를 사용하였는데 내 용에 따 
라 많이 혹은 적 게 요구할수도 있 다(크기 는 마지 막파라메터). 

3. 빈파일에 ex 任파일체계를 만든다. 

4. 파일을 올려태우기위 치 에 올려태우기한다. 이 조작은 loopback 장치를 리 용한다. 

5. 올려 태 우기 된 loopback 장치 로 변경 한다. 

6. 요구되 는 파일 들을 생 성한다(자세한것 은 아래 부분을 참고). 

7. 올려태 우기 된 loopback 장치 를 이 전시 킨다. 

8. 장치 의 올려태 우기 를 해 제 한다. 

9. 후에 리용하기 위하여 압축판본을 생 성한다. 

초기! ^ am 디스크의 내용 

사용자의 ram 디 스크에서 필요되 는 파일들은 임 의의 명 령 들을 실행 시 킬수 있는 최 소 
요구에 해당한다. 

/linuxrc msdos 파일체계를 올려 태우기 하기 위 하여 실행되는 스크맆트(아래를 보라.) 
/lib/* 동적프로그람이 요구하는 련결편집 기 와 서 고들 

/etc/* 동적련결편집 기 에 의해 리용되는 캐쉬 
/bin/* 쉘해석 기 (bash 보다 더 작으므로 ash) 


DOS 디스크들의 조종과 loopback 장치들의 설치 에 필요한 올려태우기 및 적재설치프 
로 그람들 

/dev/* 사용할 장치들. Ldlinux . so 에 대하여 / dev / zero 가 필요하다. 

/dev/hda* MSDOS 디 스크와 loopback 장치 를 위한 / dev / loop * 을 올려태 우기하기 위하 
여 필요하다. 

/mnt MSDOS 디 스크를 올려태 우기하기 위한 자유목록 


사용한 초기 ram 디 스크들을 아래 에 보여 준다. 내 용은 파일체 계의 휴지 시 간을 고려 
할 때 약 800 KB 정도 된다. 


total 18 

drwxr-xr-x 

drwxr-xr-x 

drwxr-xr-x 

drwxr-xr-x 


2 root root 
2 root root 
2 root root 
2 root root 


1024 Jun 2 
1024 Jun 2 
1024 May 20 
1024 May 27 


13:57 bin 
13:47 dev 
17:43 etc 
07:57 lib 
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우의것 들에 대 하여 유일 하게 복잡한 단계 는 dev 에 있는 장치 들에 있 다. 장치 들을 생 
성 하기 위하여 mknod 를 사용하며 요구되 는 파라메터 들을 얻 기 위한 형타적 인 요소로 
/ dev 안에 있 는 현존장치 들을 리용한다. 

/linuxrc 파일 

초기 ram 디 스크의 / linuxrc 파일은 loopback 장치 들이 뿌리구획 에 리용될수 있도록 모든 
준비를 갖추어 주는데 리용된다. 

다음의 실례 는 / dev / hdal 을 MSDOS 구획 으로 올려태 우기하며 만일 올려태우기 가 성 공 
하면 / lim ^/ linuxswp . img 파일 을 / dev / loopO 으로 설 치 하며 / linux / linuxswp . img - f - / dev/loop 1 로 
설정하는 경우의 실례이다. 


echo INITRD : Trying to mount/dev/hdal as msdos 
if/bin/mount -n -t msdos / dev/hdal / mnt; then 
echo INITRD : Mounted OK 

/bin/losetup/dev/loop0/mnt/linux/linuxdsk.img 
/bin/losetup/dev/loopl/mnt/linux/linuxswp.img 
exit 0 
else 

echo INITRD;Mount faild 
exit 1 
fi 


첫 번째 장치 / dev / loopO 은 뿌리장치 로 되 며 두번째 장치 dev / loopl 은 교환용예 비장치 
로 된다. 

만일 사용자가 DOS 구획을 뿌리 아닌 사용자로서 쓸수 있게 하려면 mount _n - 1 
msdos / dev / hdal / mnt -0 uid =0, gid =0, umask =000 을 리 용해 야 한다. 이 조작은 DOS 구획 에 대 
한 접근을 뿌리 로 넘 기게 되며 적 합한 허 가권을 설정한다. 

3.4. 뿌리장치생성 

사용자가 리 용하게 될 뿌리 장치 는 linuxdsk . img 파일 이 다. 사용자는 초기 ram 디 스크를 
생성할 때와 꼭 같은 방법으로 이 뿌리장치를 생성하여야 하는데 더 크게 생성할 필요 
는 없 다. 

이 디스크에 사용자가 좋아 하는 임의의 linux 설치프로그람을 설치할수 있다. 

제 일 쉬운 방법은 현존 linux 설치프로그람을 디스크로 복사하는것 이 다. 다른 방법은 
새 로운 linux 설 치 프로그람을 디 스크에 설 치하는것 이 다. 이 조작이 수행 되 였 다고 가정 하 
면 일부 약간의 변경을 가해 주어야 한다. 

/ etc / fstab 파일은 뿌리구획 과 초기 ram 디 스크에 설정 되 는 두개 의 loopback 장치 를 리용 
하는 교환조작을 참조하여야 한다. 
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/dev/loopO / etc2 defaults 1 1 

/ dev/loopl swap swap defaults 1 1 

이 조작은 실지 뿌리장치가 리용될 때 핵심부가 뿌리장치 가 있는 곳을 혼돈하지 않 
는다는것을 담보한다. 또한 이 조작은 교환구획 이 표준적으로 리용될 때와 같은 방법으 
로 교환공간을 첨가할수 있게 한다. 사용자는 뿌리 디스크장치나 혹은 교환구획에 대한 
그 어떤 다른 참조값을 제거해야 한다. 

만일 Linux 가 출발한 다음에 DOS 구획 을 읽 을수 있게 하려 면 일정한 여 유를 가지 고 
약간의 변환을 주어 야 한다. 

▼ /initrd 라는 등록부를 만든다. 이 등록부는 일 단 loopback 뿌리파일 체 계 가 올려태 우 
기되면 초기 ram 디 스크가 올려태 우기되 는 장소이 다. 

• 실지 DOS 구획 이 올려 태 우기 될 /initrd/mnt 를 지 적 하는 /DOS 라는 기 호적 련결을 생 
성 한다. 

▲ 디 스크를 올려 태 우기 하는 re 파일 에 한개 행 을 보충한다. 이 조작은 mount-f-t 
msdos/dev/hdal/initrd/mnt 명 령 을 실행 해 야 한다. 이 조작은 DOS 구획 에 “fake” 올 
려태 우기 를 생 성하게 되 며 따라서 모든 프로그람들은 (df 와 같은) DOS 구획 에 올 
려태우기되며 그것을 어 디서 찾을수 있는가를 알수 있게 된다. 만일 사용자가 
/linuxrc 파일에서 다른 선택 항목을 리용했다면 명백 히 그 항목을 여 기서 리용해 야 
한다. 초기 에 이 미 적재된 다음부터 는 이 뿌리장치 에 Linux 핵 심 부를 설정할 필요 
가 없다. 그러 나 만일 모둘들을 리용한다면 그 모둘들을 표준적 으로 이 장치 에 
포함시켜 야 한다. 

3.5. 교환장치생성 

사용자가 리 용할 뿌리 장치 는 linuxswap.img 파일 이 다. 교환장치 는 만들기 가 아주 쉽 다. 
초기 ram 디스크를 만들 때처럼 빈 파일을 만들고 그것을 초기화하기 위 하여 mkswap 
linuxswap.img 를 실 행한다. 

교환공간의 크기는 사용자가 설치된 체계로 무슨 작업을 하는가 하는데 의존하는데 
사용자가 가지 고 있는 RAM 의 크기와 8MB 사이 에서 선택할것을 권고한다. 

3.6. MSDOS 등록부생성 

사용하려고 하는 파일들을 DOS 구획으로 옮겨야 할 필요가 있다. C : \Linux 라고 부 
르는 DOS 등록부에서 요구되는 파일들은 다음과 같은것들이 다. 

▼ LinuxDSK. IMG 뿌리장치 로 되 는 디 스크이 메 지 

▲ LinuxSWP. IMG 교환공간 

3.7. 기동플로피디스크생성 

여 기 에서 리용할 기동디 스크는 곧 표준 DOS 양식의 기동가능한 플로피 디 스크를 말한 
다. 이 디 스크는 DOS 상에 서 format a : /s 명 령 을 리 용하여 생 성 할수 있 다. 이 디 스크상에 
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서 사용자는 AUTOEXEC . BAT 파일(아래에서와 같이)을 만들어야 하며 핵심부를 복사하 
고 실행 가능한 LOADLIN 과 압축초기 ram 디스크를 생성해 야 한다. 

▼ AUTOEXEC . BAT DOS 를 자동적 으로 실 행 하는 일 괄파일 

• LOADLIN . EXE 실행가능한 LOADLIN 프로그람 

• ZIMAGE Linux 핵 심 부 

▲ INLTRDGZ.IMG 압축된 초기 ram 디스크 

AUTOEXEC . BAT 파일은 아래와 같은 한개의 행을 포함하여 야 한다. 


\loadlin/zlmage initrd=\initrdgz. img root=/dev/loopO ro 


이 명령은 사용할 핵심부이메지，초기 ram 디스크이메지 그리고 초기 ram 디스크가 완료된후 
의 뿌리장치 들을 정 의하며 뿌리구획 이 읽 기방식 으로만 올려태 우기될것 이 라는것 을 정 의한다. 

4. 체계의 기동 

새 기동장치로부터 체계를 기동하기 위하여 요구되는것은 우에서 설명한 과정을 통 
하여 준비된 플로피디스크를 개인용콤퓨터에 끼워 넣는것이다. 

기동을 위 한 동작순서는 다음과 갈다. 


1. DOS 기동 

2. AUTOEXEC . BAT 출발 

3. LOADUN 실행 

4. Linux 핵 심 부의 기 억 에 로의 복사 

5. 초기 ram 디스크의 기억에로의 복사 

6. Linux 핵 심 부의 실 행 시 작 

7. 초기 ram 디스크상의 / linuxrc 파일실행 

8. DOS 구획 의 올려태 우기，뿌리장치 와 교환장치설정 

9. loopback 장치 로부터 기 동순서 렬 의 계 속 실 행 

이 동작들이 완성된후 기동디스크를 해제하고 Linux 체계를 사용한다. 

4.1 • 해결가능한 문제점 

우의 공정들에는 실패할수 있는 여러 단계들이 존재하는데 그것들이 어떤것들이며 
또 무엇 을 검 사하겠는가를 설명 하려 고 한다. DOS 기 동과정 은 화면상에 표시 되 는 MS - 
DOS starting …이라는 통보문을 보고 쉽게 알수 있다. 만일 이 통보문이 보이지 않으면 
플로피 디스크가 기동할수 없는 상태 이거 나 혹은 를퓨터 가 플로피 디스크구동기 에 의하여 
기동할수 없다는것을 말한다. 

AUTOEXEC . BAT 파일 이 파일 안에 있 는 명 령 들을 수행 할 때 기 정 값설 정 에 의 하여 화 
면상에 표시 되 지 않는것 이 다. 이 경 우에 는 LOADUN 을 시 작하는 파일안에 한개 의 명 령 


348 




행이 있게 된다. 

LOADUN 을 실행할 때 이 명 령행은 두가지 눈에 뜨이는 동작을 수행한다. 하나는 핵 
심 부를 기억에 적재 하는것이고 다른 하나는 ram 디스크를 기억에 복사하는것이다. 이 조 
작은 둘다 Loading … 통보문에 의 하여 지 시 된다. 

핵 심부는 그자체 가 압축되지 않은 상태 에서 출발한다. 이 조작은 핵 심부의 이메지가 
손상될 때 crc 오유들을 발생 시킬수 있다. 그다음 핵 심 부는 직 렬화순서렬을 실 행 하기 시 작 
한다. 이 때 직 렬 화순서렬 은 장황한 진 단통보문을 내 보내 게 된 다. 초기 ram 디 스크장치 의 
적재과정 역시 이 단계를 실행할 때 볼수 있다. 

/linuxrc 파일이 실행될 때는 진단통보문이 전혀 나타나지 않지만 오유수정도구의 지 
원으로 자체로 추가해 줄수 있다. 만일 이 단계에서 loopback 장치들을 뿌리장치로 설치하 
는데 실패하면 뿌리장치 가 없다는 통보문과 핵심부의 설치 가 보류되 였다는 통보문을 볼 
수 있을것이다. 

새 로운 뿌리장치 에 대 한 표준기동순서렬은 계속 진행되며 여 기 에는 장황한 내 용들이 
아주 많다. 읽 기 -쓰기방식 으로 올려태 우기되 고 있는 뿌리장치 에 대 하여 서 는 문제 점 들이 
있을수 있지 만 LOADUN 명 령 행의 선택 항목 “ro” 을 리 용하여 그것 을 정지 시 킬수 있다. 
다른 문제들도 발생할수 있는데 여기에는 기동순서렬이 뿌리장치가 있는 위치를 혼돈하 
여 생기는 경우가 속한다. 이 경우는 대체로 /etc/fstab 와 관련되는 문제이다. 기동순서가 
완료되 면 나머 지문제 는 프로그람들이 DOS 구획 이 올려태 우기되 였는지 혹은 올려태 우기되 
지 않았는지 에 대 하여 혼돈하는 문제 이 다. 이 때 는 이 미 설명 한 fake 올려 태 우기 명 령 을 사 
용하는것이 좋은 착상으로 될것이다. 이 명령은 DOS 장치상에서 파일에 접근하려고 할 
때 아무런 문제도 생기지 않게 한다. 

4.2. 도서목록 

첫 loopback 뿌리 파일 체 계 를 만들 때 참조한 문헌들을 아래 에 소개한다. 

▼ Linux 핵심부원천 특히 init/main.c 

• Linux 핵 심부문헌 특히 Documentation/initrd. txt 와 Documentation/ramdisk.txt 

• LILO 문헌 

▲ LOADUN 문헌 

5. 다른 Loopback 뿌리장치의 리용가능성 

일 단 DOS 구획상의 파일체계 에 의한 기동원리 가 확립되기만 하면 사용자가 그것을 
리용하여 다른 많은 문제 들을 해볼수 있 다. 

5.1 . DOS 하드디스크설정 

만일 기 동플로피 디 스크에 의하여 DOS 하드디 스크상의 파일 로부터 Linux 를 기 동할수 
있 으면 그것 은 명 백하게 하드디 스크자체 를 리용하여 역 시 기 동할수 있 다는것 을 말한다. 
배 치구성기 동차림 표로 AUTOEXEC. BAT 안으로부터 LOADUN 실 행 을 위한 선택 항목을 
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주는데 리용할수 있다. 이것을 리용하면 기동순서를 더 빨리 실행할수 있는데 그렇지 않 
은 경우에는 갈다. 

5.2. ULO 기동설치 

LOADLIN 의 리용은 Linux 핵 심 부의 기 동을 위한 한개 선 택 항목에 불과하다. LILO 도 
역시 꼭 갈은 동작을 수행하지만 DOS 를 필요로 하지 않는다. 이 경우에 DOS 양식플로피 
디 스크는 ext2 양식 의 디 스크로 교체 될 수 있 다. 그밖의 구체 적내 용들은 핵 심 부와 디 스크에 
자료를 가지 고 있는 초기 ram 디스크와 아주 류사하다. 

LOADLIN 방법을 선택하게 된것은 LILO 에 주어 져야할 인수들이 다소 복잡하다는 
데 있 다. 역 시 LOADLIN 은 DOS 조종하에 서 읽 을수 있기 때 문에 유연디 스크가 무엇 인가를 
무심 히 알게 되 는 사람들에 게 는 더 명 백하다. 

5.3. VFAT / NTFS 설치 

NTFS 방법에서는 아무러한 문제도 없었다. NTFS 파일체계구동기는 판본 2.0 에서 표준 
핵심부선택항목은 아니지만 http : "www. infomatik. hu-berlin. de/~loewis/ntfs/ 로부터 검사 
수정 으로 리용할수 있 다. 판본 2.2.x 에 서 는 NTFS 구동기 가 핵 심 부안에 표준으로 포함된 다. 

VFAT 혹은 NTFS 선택 항목들에 서 는 유일한 변화들이 초기 ram 디 스크에 있 다. /linuxrc 
파일에 대 해서 는 MS-DOS 보다는 VFAT 나 NTFS 형 파일체 계 를 올려 태 우기 할 필요가 있 다. 
이 방법 이 VFAT 구획 상에서 도 작업할수 있기때 문이 다. 

5.4. 재구획분할이 없이 Unux 설치 

표준배 포관으로부터 개 인용콤퓨터 상에 Linux 를 설 치하는 공정 은 플로피 디 스크로부터 
의 기동과 디스크의 구획재분할을 요구한다. 이 단계는 빈 loopback 장치와 교환파일을 생 
성하는 유연성기동디스크에 의하여 이루어 진다. 이 과정은 설치가 표준적으로 진행될수 
있게 하지만 구획보다는 오히려 loopback 장치에 설치되게 한다. 

이 단계는 UMSDOS 설 치와 다른 설 치 에도 리용될수 있다. ext2 파일체 계 에서 최소배정 
단위가 DOS 구획의 32KB 대신에 1KB 이기때문에 디스크의 리 용상견지에서 아주 효과적 이 다. 
또한 다른 방법으로는 문제가 생기는 VFAT 나 NTFS 양식화디스크들에서도 리용할수 있다. 

5.5. 비기동장치로부터의 기동조작 

이 방법은 표준적으로 기동할수 없는 장치로부터 Linux 체계를 기동하는데도 역시 사 
용할수 있다. 

▼ CD-ROM 

• 압축 디스크 

▲ 병렬포구디스크구동기 

다른 장치들에서도 많이 사용할수 있는데 NFS 뿌리파일체계들은 이미 선택항목으로 
핵 심부에 포함되 여 있지 만 여 기 에서 서 술한 방법 도 역 시 대 신 리용할수 있다. 
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부록 4. Linux 의 구획설정방법 


이 Linux 속성 참고서 는 사용자의 Linux 체 계 에 디 스크공간을 어 떻게 계 획 하며 구성배 치 
를 어떻게 하는가에 대하여 서술한다. 이 문서는 디스크장치，구획，교환공간크기설정，위 
치 적문제，파일체 계，형 식 그리 고 련관된 사항들에 대 하여 취 급한다. 기 본취 지 는 절 차가 
아니 라 몇 가지 기 초적지식 을 인식시 키 자는데 있다. 

1 .요약 

1.1. 문서의 목적 

이 문서는 Linux 2부류 참고서 이다. 2부류 참고서는 Linux 의 설치와 개 별지도형 식의 
주장과 관련되 는 일 부 실 무적문제 를 해 설 해 주는 간단한 문서 이 다. 이 문서 가 2부류의 
소규모적문서 로 되 는 리유는 취 급하는 내 용이 너 무 작아서 실지 적 인 참고서 와 책 이 라기 
보다 본문이나 주제정도의 사용설명서에 불과하다. 

1 . 2 . 문서의 기본내용과 련관문서 

이 특정한 2부류 참고서는 사용자가 Linux 체계를 위한 디스크공간을 어떻게 계획하 
며 어떻게 배치구성할것인가를 서술해 준다. 이 문서는 디스크장치，구획，교환공간크기 
설정，위치적문제，파일체계，파일체계형식과 관련 있는 주제들에 대하여 설명해 준다. 

기 본목적 은 몇 가지 기 초적지식 을 주는데 있으며 따라서 도구가 아니 라 편리 를 기 본 
으로 하였다. 편의상 이 문서는 설치하기전에 읽어야 하는데 어쨌든 대부분의 사람들에게 
는 어 렵 다. 처음에 는 디스크구조적배 치최 량화보다 다른 문제들이 제 기되 였다. 그리 하여 
사용자들속에서 Linux 설 치 를 완료한 다음에 설치를 최 량화하기 위한 방법과 계 산정 확도를 
높이 기 위한 방법 을 생 각하기 시 작하였 다. 이 본문을 읽 고 Linux 설 치 를 완료체 계 로 다시 
해체 하고 재구성해 보고 싶은 욕망이 생 기게 될것 이 다. 이 2부류 참고서는 자체 가 디스크 
공간을 대 역 분할하고 계 획 하는데 서 일 정 한 제 한을 가지 고 있 다. 여 기 서 는 fdisk 의 리 용과 
LILO , mke 2 fs 나 혹은 여벌 복사프로그람은 론의 하지 않는다. 이러한 문제들을 취급하는 다 
른 참고서 들이 있 다. LinuxHOWTO 에 관한 현행 문헌들에 대 하여 서 는 LinuxHOWTO 색 인을 
보면 된다. 색 인으로 HOWTO 문서들을 얻을수 있는 지도서들도 나와 있다. 

▼ 파일체계의 서로 다른 부분들에 대한 여러가지 크기와 속도요구를 어떻게 평가 
하는가를 알 기 위 하여 서 는 Gjoen Stein “ Linux Multiple Disks Layout mini - 
HOWTO ” 를 보면 된다. 

• 1024이상의 실린더를 가진 디스크를 고찰하는 지도서와 고려사항은 Andries 
Brouwer 가 쓴 “Linux Large Disk mini - HOWTO ” 를 보면 된다. 
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▲ 사용자당(배 정 량) 디 스크공간리 용의 제 한에 대 한 지 도서 로는 Albert M. C. Tam 이 
쓴 “Linux Quota mini-HOWTO” 를 보면 된다. 

현재 디스크의 여벌복사에 대한 일반적인 문헌은 없지만 특정한 여벌복사해결안에 
대 한 지 적자를 가지 는 몇 가지 문헌들은 있 다. Linux 를 IBM ADSM 여 벌복사환경 으로 종합 
하는 지 도서 로는 Thomas Koening 이 쓴 “Linux ADSM Backup mini-HOWTO ” 를 보면 
된 다 . MS-DOS 구동형 Linux 여벌복사에 대한 정보는 Christopher Neufeld 가 쓴 “ Linux 
Backup with MS-DOS mini-HOWTO ；， 를 볼수 있 다. 

HOWTO 문헌의 제시와 기록에 대한 지도서로는 Tim Bynum 이 쓴 “Linux HOWTO 
Index” 를 보며 /usr/src/Linux/Documentation 을 브라우저를 통하여 열람하는 방법으로도 역 
시 도움을 받을수 있다. 사용자의 디스크구동기의 속성 에 관한 몇 가지 기본정보는 ide.txt 
와 scsi.txt 를 참고할수 있으며 파일체계/부분등록부를 찾아 볼수 있다. 


2. 구획에 대한 개념 

개인용콤퓨터의 하드디스크들은 체계가 비록 한개의 디스크만을 가지고 있었지만 다 
중조작체계를 설치해 보려는 사람들에 의하여 즉시 발명되였다. 

그로부터 단일한 물리적디스크를 다중론리디스크들로 분할하기 위한 기술이 요구되 
였다. 바로 그것이 구획이다. 완전히 분리된 디스크와 같이 취급되는 사용자하드디스크의 
련속적인 블로크부분은 거의나 조작체계에 의하여 실현되였다. 구획들이 중복되지 말아 
야 한다는것은 명백하나 같은 기계에 설치된 서로 다른 조작체계가 중복구획들때문에 중 
요한 정보들이 덧씌여 지면 안된다. 린접한 구획들사이에는 역시 름이 없어야 한다. 만일 
름을 주어도 해롭지 않다면 구획들사이에 공간을 남겨 두는 방법으로 선행디스크공간을 
랑비하게 된다. 디스크는 구획으로 완전히 분할될것을 요구하지 않는다. 사용자는 자기의 
디스크끝에 일정한 공간을 남겨 둘것을 예견할수도 있다. 이때 사용자디스크의 끝은 여 
전히 설치된 조작체계의 그 어떤 부분도 지적하지 못한다. 설치가 사용자에 의하여 대부 
분 시간동안 리용되였다는것이 명백할 때 사용자는 이 나머지부분을 공간상에 구획으로 
설정할수 있으며 거기에 파일체계를 배치한다. 구획들은 옮겨 질수 없으며 그안에 포함 
되여 있는 파일체계를 소거하지 않고는 재배치할수도 없다. 그런데로부터 구획의 재구성 
은 보통 여벌복사와 구획재구성시에 변경된 모든 파일체계를 회복하는 동작이 동반된다. 
사실 구획재구성시 에는 모든것 이 뒤 죽박죽된다는것 이 명백 한 공통적 현상이며 따라서 사 
용자는 지어 fdisk 들과 같은 프로그람으로 다처 놓기전에 특정한 를퓨터의 임의의 디스크 
에 있는 정보들을 여벌복사해 두어야 한다. 

디스크우에 어떤 파일체계형을 가진 일부 구획들은 실제적으로 자료를 잃어 버림이 
없이 두개 로 분할될수 있다. 실례 로 MS-DOS 를 재설치하지 않고 Linux 설치 를 위 한 대 역 
을 확보하기 위하여 MS-DOS 구획 을 두개 로 분할하기 위한 “fips” 라는 프로그람이 있 다. 
그러나 사용자들은 아직도 여전히 자기의 콤퓨터상의 모든것을 주의 깊게 여벌복사해 두 
지 않고서는 이 조작을 하려고 하지 않는다. 
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2.1 . 여벌복사의 중요성 

레프장치들은 여벌복사의 중요한 수단이다. 테프장치들은 속도도 빠르고 현실성이 
있으며 사용하기 쉽다. 그리하여 사용자들은 흔히 혼란이 없이 완전히 자동적으로 여벌 
복사를 실현할수 있다. 

여 기서 는 디 스크조종장치 로 구동되 는 ftape 를 념 두에 두는것 이 아니 라 실제레 프에 대 
하여 말한다. SCSI 를 도입하는 경 우를 고찰하자. Linux 는 SCSI 를 선천적 으로 지 원하지 
못한다. 사용자는 ASPI 구동기 를 적 재할것 을 요구하지 못하며 Linux 상태 에 서 정 확한 
HMA 를 적재하지 못하며 또 일단 SCSI 주적응기 가 설치되면 보충적 인 디스크，테프장치 
그리 고 CD - ROM 을 그우에 추가할수 있다. 그이상의 I 八)주소, mQ 조작이 나 마스트/슬라브 
그리 고 PIO 준위 정 합은 없 다. 고유한 SCSI 주적 응기 들은 CPU 를 더 적 재하지 않고도 높은 
I / O 성능을 제공한다. 둔한 디스크동작하에서도 사용자는 괜찮은 응답시간을 경험적으로 
엄 을수 있다. 만일 사용자가 기 본 USENET 새 소식원천으로 Linux 체 계 를 리용하려 고 계 
획하거 나 혹은 ISP 업무에 리용하려 고 한다면 SCSI 없 이 체 계를 전개하는 문제 에 대 해서 
는 생각조차 할수 없다. 

2.2. 장치번호와 장치이 ■ 

인 텔 에 기 초한 체 계 에 서 구획 의 수는 애 당초 제 한되 였 다. 초기 의 구획 표는 기 동씩 터 
부분으로서 설 치되 였으며 오직 4개의 구획입구점공간만을 가지 였다. 이 구획들은 지금 1 
차구획 이라고 부론다. 사람들이 체 계 상에 보다 많은 구획 을 가질 것 을 요구한다는것 이 명 
백 해 졌을 때 론리 구획 이 발명 되 였 다. 

론리구획 의 수는 제 한이 없 다. 매 개 론리구획 은 다음의 론리구획 에 대 한 지 적자를 
포함하며 따라서 사용자는 잠재 적 으로 제 한이 없는 구획입 구점 들을 가질수 있게 되 였 다. 
호환성 으로 하여 모든 론리구획 이 차지한 공간은 계 산되 여 야 하였 다. 만일 사용자가 론 
리 구획 을 리 용하고 있 다면 하나의 1차구획 의 입 구점 은《 확장구획 》 (extended partition ) 으 
로 표기되며 그것의 시작과 끝블로크는 사용자의 론리구획이 차지한 대역을 표시한다. 
이것은 전체 론리구획에 지정된 공간이 련속적이여야 한다는것을 의미한다. 오직 한개의 
확장구획만 있을수도 있다. fdisk 프로그람은 하나이상의 확장구획보다 더 큰 구획을 생성 
할수 없다. 

Linux 는 구동기 당 제 한된 수의 구획 보다 큰 구획 을 조종할수 없 다. 그리하여 Linux 에 
서 는 사용자가 4개 의 1차구획 (론리구획 을 리용하면 그들중 3개 는 리용할수 없 다.)과 하나 
의 SCSI 디 스크상에 기껏 해 서 15개 의 구획 을 가질수 있 다(正®디 스크상에 서 는 전체 적 으로 
63개). 

Linux 에 서 구획 들은 장치파일 에 의하여 표현된 다. 장치파일 은 형 c (캐쉬 를 
리용하지 않는 장치 로서 《 문자》장치 ) 혹은 형 b (캐쉬 를 거 처 리용되 는 장치 로 
서 《 블로크》장치 )의 파일 이다. Linux 에 서 모든 디 스크들은 블로크장치 로만 표 
시 된다. 다른 범 용장치 들과 달리 Linux 는 《 행》속성판본의 디 스크와 그것 의 구 
획을 제공하지 못한다. 

장치 파일 의 유일 하게 중요한 내 용은 그것 의 기 본 ( major ) 및 부 ( minor ) 장치 번 호인데 
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주로 파일크기대신 주어 진다. 

$ Is ；i ^|. /dev/hda 

brw-rw - 舍 ; 分 。 t disk 3 ， 0 Jul 18 1994 /dev/hda 

I 부장치번호 

주장치 번 호 

장치파일 에 접 근할 때 주번 호는 어 느 장치구동기 가 입 출력조작을 수행 하기 위하여 
호출되 고 있는가를 선택한다. 이 호출은 파라메터 로서 부번호에 의하여 수행 되며 이 것은 
구동기가 부번호를 어떻게 해석하는가에 전적으로 달려 있다. 

구동기문서는 보통 구동기가 부번호를 어떻게 시동하는가를 서술해 준다. IDE 디스크 
에 대 한 문 서 는 / usr / src / Documentation / ide.txt 에 있 다 . SCSI 디 스 크 들 에 대 하 여 서 는 
/ usr / src / linux / Documentation / scsi.txt 에서 기대 할수 있겠지만 거 기 에는 없다. 믿을수 있는 구 
동기원천은 / usr / src / linux / driver / scsi / sd . c : 184-196 에 서 찾아야 한다. Peter Anvin 의 구동기 
번호와 이름목록은 / usr / src / linux / Documentation / devices.txt 에 있다. 여기서 전체 블로크장치 
즉 주번 호 3, 22, 33, 34 (IDE 용)와 SCSI 디 스크들을 위한 주번 호 8을 찾을수 있 다. 주번 호 
와 부번호들은 다 한바이트로 되여 있는데 그 리유는 매 디스크당 구획수가 제한되여 있 
기 때문이다. 

관례 에 따라 장치파일 들은 어 떤 이 름을 가지 고 있 으며 많은 체 계프로그람들은 콤파 
일되는 이 이름들에 대한 지식을 가지고 있다. 그러한 이름들로는 IDE 디스크에 대하여 
/ dev / hd *, SCSI 디 스크들에 대 하여서 는 / dev / sd * 로 표현하며 개 별적디스크들은 a , b , c 등으 
로 번 호를 붙인 다. 그러 므로 / dev/hda 는 IDE 디 스크들중의 첫번째 디 스크를 가리키 며 
/ dev/sda 는 SCSI 디 스크의 첫 번째 를 가리킨다. 두 장치 著은 다 블로크디 스크에 서 출발하여 
전체 디스크를 표현한다. 불량한 도구들을 가지고 이러한 장치들에 대하여 쓰기를 진행 
하면 디 스크상의 기 본기 동적 재 프로그람과 구획 표를 파괴하게 되 며 따라서 디 스크의 모든 
자료를 못쓰게 만들거나 혹숀 체계가 기동할수 없게 한다. 이런 현상이 나타나기전에 상 
태 를 알아야 하며 여 벌복사를 진행해 야 한다. 

디 스크상의 1 차구획 은 1, 2, 3, 4이 다. 따라서 / dev/hdal 은 첫 IDE 디 스크의 첫 번째 
1차구획으로 된다. / dev / hda 2 는 두번째 2차구획 등으로 된다. 론리구획은 5이상의 번호를 
가지는데 / dev / sdb 5 는 2차 SCSI 디스크의 첫번째 론리구획 으로 된다. 

매개 구획의 입구는 그것을 지적하는 시작블로크와 끝블로크의 주소를 가지고 있다. 
형은 어떤 형의 조작체 계 에 대 한 특정한 구획을 가리키는 수자코드(한바이트)로 되여 있 
다. 호환성 을 보장하기 위하여 구획 형 코드는 단계 적 으로 유일 하지 않으며 따라서 두개 의 
조작체계 가 같은 형코드를 리용할 가능성은 언제 나 있다. 

Linux 는 교환구획 에 대 하여 0 x 82, 고유 ( “ native ” ) 파일 체 계 (대 체 로 ext 2 fs ) 에 대 하여 
서 는 0 x 83 의 형코드를 보존하고 있다. 한때 대 중화되 였 고 지 금은 구식 에 불과한 
Linux/Minix 파일 체 계 는 구획형코드로 0 x 81 을 리용하였 다. OS /2 는 구획형코드를 0 x 07 로 
표기 하며 WindowsNT 의 NTFS 도 이 값을 리 용한다. MS-DOS 는 FAT 파일 체 계 의 특색 에 
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맞게 여 러 가지 형 코드를 배 정한다. 그러한 형 코드로는 0 x 01，0 x 04, 0 x 06 이 알려 져 있 다. 
DR - DOS 는 어떤 때는 Linux / Minix 와 충돌하기도 하면서 보호방식 용구획을 지 적 하는데 
0 x 81 을 리용하였지 만 Linux / Minix 나 DR - DOS 에 더 이 상 리용하지 않는다. 론리구획 의 저 
장통으로 리용되 는 확장구획 은 0 x 05 형코드를 리용한다. 

구획 은 fdisk 프로그람으로 생 성하거 나 소거한다. 매 개 자체 조작체 계 프로그람은 fdisk 
를 리용하며 전통적 으로 거의 모든 조작체계들에서 Msk (혹은 Misk . exe ) 라고 부르고 있다. 
일부 fdisk 들은 다른 조작체계들의 구획을 취급할 때 제한성을 가지게 된다. 이러한 제한 
성으로 하여 다른 체계의 형코드로 객체를 취급할수 없으며 1024개이상의 실린더를 다룰 
수 없고 구획의 생성이나 지어 실린더경계에 구획의 끝이 놓이지 않는다는것도 알수 없 
게 된다. 실례로 MS - DOS 의 fdisk 는 NTFS 의 구획을 지을수 없으며 OS /2 의 fdisk 는 Linux 
의 fdisk 에 의하여 생성된 실린더경계에 끝이 놓이지 않는 구획을《정확한》것으로 리해 
하며 DOS 와 OS /2 은 둘다 1024개 이상의 실린더를 가진 디스크에서 비정상상태를 나타낸 
다(이 디 스크들에 대 한 자세 한 내 용은 “ large - disk ” Mini - Howto 를 참조할것 ). 

3. 구획의 기본내용 

3.1 . 구획의 분할 

일부 조작체계들은 정상적 인 사고를 초월하는 리유들로 하여 론리구획으로부터의 기 
동을 믿지 않는다. 대체로 사용자들은 MS-DOS 나 OS /2 그리고 Linux 가 리용할 조작체계 
를 위한 기동구획으로서 1차구획을 예약하려고 한다. 하나의 구획이 확장구획으로 되여 
야 하며 그 확장구획 은 론리구획 을 포함하는 디 스크의 나머 지 부분들에 대 하여 저 장통으 
로 쓰인다는것을 잊지 말아야 한다. 

조작체 계 의 기 동은 BIOS 와 1024개 실 린 더 한계 를 포함하는 실 방식 기 동이 다. 그러 므로 
사용자는 이 러 저 러 한 문제 들을 피 하기 위하여 자기 의 모든 기 동구획 을 하드디 스크의 첫 
1024개실 린더 에 놓으러 고 한다. 

Linux 를 설치하기 위하여서는 사용자에게 적어도 한개의 구획이 있어야 한다. 만 
일 핵 심부가 이 구획 으로부터 적재된다면(실례 로 LILO 에 의하여) 이 구획은 반드시 
BIOS 에 의하여 읽 혀 져 야 한다. 만일 사용자가 핵 심 부를 적재하는데 다른 수단(실 례 
로 기 동디 스크나 혹은 MS - DOS 에 기 초한 Linux 적 재프로그람 LOADLIN . EXE ) 을 리용 
한다면 그 구획 은 아무것 이 라도 된다. 이 경 우에 구획 은 〈〈Linux 고유》 0 x 83 형 식 으로 
될것이다. 

사용자의 체계가 약간의 교환공간을 요구할수 있다. 또한 사용자가 파일들에 대한 
교환조작을 해야 할 경우에는 지정된 교환구획을 요구하게 된다. 이 구획은 오직 Linux 
핵 심 부에 의 하여 서 만 접 근되 기 때 문에 PC BIOS 가 없 다고 하여 도 Linux 핵 심 부가 불리 한 
상태 에 처하지 않기 때 문에 교환구획 은 아무데 나 놓여 도 된 다. 

3.2. 교환공간배정 

일반적으로 사용자가 좋은 방법으로 알려 진 하나의 교환구획을 리용하려고 결심하 
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면 교환구획의 크기를 평가하기 위하여 이 안내내용을 참고해도 된다. 

Linux 에서 RAM 과 교환공간은 합쳐 져 있다(물론 모든 UNIX 계 에서는 아니 다.). 
실례 로 만일 사용자가 8MB 의 RAM 과 12MB 의 교환공간을 가지 고 있으면 전체 적 으 
로 20MB 의 가상기억을 가져야 한다. 그러므로 4MB 의 RAM 에 대하여 적어도 12MB 
의 교환공간을 생각할수 있으며 8MB 의 RAM 에 대 하여서는 8MB 의 공간을 생각할수 
있 다. 

Linux 에 서 단일교환구획 은 128MB 보다 콜수 없 다. 즉 구획 은 128MB 보다 콜수 있지 
만 초과공간은 리용될 수 없 다. 만일 128MB 보다 큰 교환공간을 만들려 면 다중교환구획 을 
생성해 야 한다. 

교환공간크기를 정할 때 너무 크게 교환공간을 정하면 전혀 쓸모가 없다는데 대 
하여 생각해야 한다. 매개 프로쎄스는 《작업모임》을 가지는데 이것은 제일 처음 참 
조하게 될 기억안폐지의 모임이다. Linux 는 이 기억접근을 예측하여(제일 최근에 리용 
한 페지 들이 다시 제 일 먼 저 리용된 다고 가정 하여 ) 가능하면 RAM 에 이 페지 들을 보 
존하려고 한다. 

만일 프로그람이 파괴된 《참조위치》를 찾는다면 이 가정은 맞는것으로 될것이며 
예 측알고리 듬이 동작하게 된 다. 주기억안의 작업 모임 을 유지 하는 조작은 주기억 이 충분 
할 때에만 동작가능하게 된다. 콤퓨터안에 실행중에 있는 프로쎄스가 너무 많으면 핵심 
부는 제 일 처 음에 다시 참조해 야 할 디 스크상에 폐 지 들을 배 치하도록 요구한다(다른 작 
업모임 으로부터 폐지를 내 보내게 하고 참조된 폐지 안에 그 페지를 넣는다.). 보통 이 조 
작은 페지 화조작이 극도로 증가되 게 하는 결과를 발생하는데 이 때 성 능이 크게 떨 어 진 
다. 이 상태 에 있는 콤퓨터 를《헛수고》상태 에 있다고 말한다. 

《헛수고》상태 에 있는 콤퓨터 에서 프로쎄 스들은 본질적 으로 RAM 으로부터 가 아니 
라 디스크로부터 실행되게 된다. 이때의 성능은 기억접근속도와 디스크접근속도의 비에 
의하여 대 략적 으로 떨 어 지 리 라고 예 측할수 있 다. 

한때 PDP 와 Vax 에 서 리용한 변경 된 규칙 에 의하면 프로그람의 작업 모임 의 크기 는 
가상크기의 25% 였다. 따라서 대체적으로 RAM 크기의 3 배보다 더 큰 교환공간을 준비하 
는것은 의의가 없다. 이것이 바로 “thumb” 의 규칙이라는것을 상기해 둔다. 

프로그람들이 매우 크거나 혹은 매우 작은 작업모임을 가지도록 동작순서를 쉽게 만 
들수 있 다. 실례 로 아주 우연적 인 양상으로 접 근될수 있는 큰 자료모임 을 가지 는 모의프 
로그람은 자료토막안에서 뚜렷한 참조위 치를 거의 가지지 않으며 따라서 그것의 작업모 
임은 커지게 된다. 

바꾸어 말하면 동시 에 열린 많은 JPEG 들을 포함한 XV 는 전부는 아니 지 만 그림 
문자 (icon) 형식으로 되여 있으며 매우 큰 자료토막을 가지고 있다. 하지만 화상변화 
는 모두 하나의 단일화상우에서 실현되며 XV 가 차지한 대부분의 기 억은 다칠수 없 
다. 동시에 한개 창문만 변경시킬수 있는 여러개의 편집기창문을 가진 편집기들에서 
는 사실상 이것이 동일하다. 이 프로그람들은 제대로만 설계되면 고도의 위치참조성 
을 가지 며 그 프로그람의 큰 부분은 심한 성 능상 충돌이 없 이 교환동작을 진행할수 
있 다. 

누구나 명 령 자체 가 낡았다는데 로부터 25% 의 수가 다중문서 를 편집하는 현대 적 인 
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GUI 프로그람들에서는 더 이상 적합하지 않다는것을 알고 있으나 이 수자들을 검증해 볼 
수 있는 새로운 자료들은 물론 없다. 

지 금까지 16 MB 에 의한 배 치구성 에 대 해서 는 최 소배 치 구성 을 요구하는 교환이 전혀 
없었고 48 MB 보다 큰 교환은 대체 로 리용하지 않았다. 요구되는 기 억의 정 확한 크기는 
콤퓨터 에서 실행 되 는 응용프로그람에 의 존한다. 

3.3. 교환공간의 배치위치 

기계는 뜨고 전자공학적요소는 빠르다. 현대적하드디스크들은 여러가지 자두를 가지 
고 있다. 같은 자리길우에서 자두들의 절환은 그 동작이 순수 전자공학적 작용에 기초하 
므로 빠르다. 그러나 자리길사이의 절환은 기계적현상을 포함하기때문에 뜨다. 

그러므로 자두가 많은 디스크나 혹은 더 적은 디스크를 가지고 있거나 두개가 서로 
다른 파라메 터를 가지고 있다고 할 때 많은 자두를 가지고 있는 디스크의 속도가 더 빠 
르다. 교환장치를 분할하고 두개의 디스크에 배 치 하여도 속도는 빨라 진다. 

변경된 디스크들은 모든 자리길우에 동일한 쌕터수를 가지고 있다. 이러한 디스크들 
에서 디스크의 자두가 임의의 자리길로부터 교환대역쪽으로 움직일것이라고 가정하면 디 
스크의 중간에 자두를 놓는것이 제일 빠르게 될것이다. 

보다 새로운 디스크들은 ZBR (기록비트대역)를 사용한다. 이 디스크들은 바깥쪽자리 
길 에 더 많은 쌕터 들을 가지 고 있다. 고정 된 수의 rpm 에 의하여 이 방식 은 안쪽의 자리 
길보다 바깥쪽자리 길 에서 더 높은 성 능을 발휘한다. 그러 므로 빠른 자리길 에 교환기억 을 
놓는것이 좋다. 

물론 디스크자두는 제멋대로 움직이지는 않는다. 만일 사용자가 불변동작홈，구획 그 
리 고 대 다수 리용되 지 않는 압축구획 들사이 에 중간크기 의 교환공간을 가지 고 있으면 교 
환장치가 보다 짧은 자두의 움직임에 대해서도 홈구획의 중간에 있을 때 상태가 더 좋아 
진 다. 

요약 다른 일 을 하는 동작중이 아닌 여 러개의 자두를 가진 고속디 스크에 사용자의 
교환공간을 배 치한다. 만일 사용자가 다중디 스크를 가지 고 있 다면 교환공간을 분할하고 
그것을 모든 디스크에 혹은 다른 조종장치에 나누어 준다. 상태가 좋아 지면 더 많은 
RAM 을 준비할수 있 다. 

3.4. 파일체계와 단편화 

디 스크공간은 조작체 계 에 의하여 블로크나 블로크들의 조각을 단위 로 관리 된다. ext 2 
파일체 계 에서 조각들과 블로크들은 갈은 크기 를 가져 야 하며 따라서 우리의 론의문제 를 
블로크에 대 한 문제 로 제 한할수 있다. 

파일은 임의의 크기를 가질수 있다. 또한 파일은 블로크경계의 끝과 일치되지 않 
는다. 그러 므로 매 개 파일 에 서 파일 의 마지 막블로크부분은 랑비 된 다. 파일크기 가 임 의 
라고 가정하면 디스크상에서 매개 파일에 대하여 대 략적으로 블로크의 절반이 랑비된 
다. 타넨바움 ( Tanenbaum ) 은 이 내용을 자기의 저서 《조작체계》에서 《내부단편화》 
라고 불렀다. 
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사용자는 디스크에 배정된 색인마디의 수에 의하여 디스크상의 파일수를 추측할수 
있다. 디스크상에서 이 내용은 다음과 같이 서술된다. 

# df -i 


Filesystem 

Inodes 

Iused 

Ifree 

%Iused 

Mounted on 

/ dev / hda 3 

64256 

12234 

52022 

19% 

/ 

/ dev / hda 5 

96000 

43058 

52942 

45% 

/var 


보는바와 같이 /우에는 약 12000개의 파일 이 있으며 /var 에는 44000개의 파일 이 있 다. 
만일 블로크크기 를 4 KB 로 선택 했 다면 이 공간의 4배 를 잃을수도 있다. 자료전송은 큰 
자료의 련속덩어리에서 더 빠르다. 그것은 ext 2 이 파일에 대하여 8개의 련속된 블로크단 
위 로 공간을 선 행 배 정 하기 때 문이 다. 

리용되지 않는 선행배정 은 파일 이 닫길 때 개 방되 며 따라서 랑비되 는 공간은 없다. 
파일안에 블로크들을 불련속적 으로 배 치하는것 은 성 능상 견지 에 서 좋은것 이 못된 다. 왜 냐 
하면 파일들은 흔히 순차적방식 으로 접 근되 기 때 문이 다. 

조작체 계 들에 서 는 디 스크접 근을 분할하도록 요구하며 디 스크가 자두를 움직이 도록 
요구한다. 이것을《외부단편화》혹은 단순히 《단편화》라고 부르며 이것은 DOS 파일 
체 계 에 서 공통적 문제 이 다. 

ext 2 파일 체 계 는 외 부단편화를 극복하기 위한 몇 가지 방책 을 가지 고 있 다. 표준적 으로 
ext 2 에서 단편화는 큰 문제 가 아니 며 지 어 USENET 새 소식 spool 과 같은 구획 에도 중요 
하게 리용되 지 않는다. 

ext 2 파일 체 계 의 비 단편화를 위한 도구가 있기 는 하지 만 누구도 그것 을 리용하지 않 
으며 현재 까지 도 ex 任의 현 행판본에 서 리용하지 않는다. 

MS-DOS 파일체계가 디스크공간의 관리를 치료적으로 진행한다는데 대해서는 잘 알 
려 져 있다. MS-DOS 에 의하여 리용된 아주 불량한 캐쉬와 관련하여 파일단편화의 효과 
는 아주 주목할만하다. DOS 사용자들은 몇주일 에 한번씩 디 스크들의 조각을 모아 두는데 
습관되 였으며 일부 사람들은 조각모으기 를 전문화하는 의식적 인 도구까지 개 발하였다. 
Linux 와 ext 2 에 서 는 이 러 한 습관적 행 동을 취 할 필 요가 없 다. 

MS-DOS 파일체계는 또한 내부적 인 단편화로 인하여 많은 량의 디스크공간을 루실하 
는것으로 알려 져 있다. 256 MB 보다 큰 구획에서 DOS 블로크크기는 커지게 되며 따라서 
더이상 쓸모 없게 된다(이 부족점은 FAT 32 에 의한 일부 확장체계에서는 수정되였다.). 
ext 2 는 사용자로 하여금 0.5 TB 나 그이상의 아주 큰 파일체 계 (1 TB 는 1024 GB ) 들을 제외하 
고는 큰 파일 체 계 들의 블로크들을 선택할수 있 게 한다. 0.5 TB 이 상 규모의 큰 파일 체 계 에 
서 는 작은 블로크크기 가 효과성 을 가지 지 못한다. DOS 와 다른 체 계 들에서 는 큰 디 스크 
들을 블로크크기 가 작은 다중구획들로 쪼갤 필요가 없다. 가능하면 블로크크기 를 기정값 
으로 지정된 1 KB 를 사용하면 된다. 사용자가 일부 구획에 대하여 2 KB 의 크기를 가진 블 
로크를 실험해 보려 하지 만 오유가 생길수 있 다고 예 측할수 있다. 대 부분의 사람들은 기 
정값을 쓴다. 
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3.5. 구획 평가기준으로서의 파일수명과 여벌복사주기 

ext 2 에 의하여 구획 을 설 정하려 고 하면 서 로 다른 파일 수명 으로부터 외 부단편화를 
피 하기 위한 여 벌 복사방법 으로 관리하여 야 한다. 파일 은 수명 을 가지 고 있 다. 파일 은 일 
단 생성된후에 일정한 시 간동안 체계에 남아 있으며 후에 제거된다. 파일수명은 체계전 
체에 걸쳐 크게 달라 지며 특히 파일의 경로이름에 부분적으로 의존한다. 실례로 / bin , 
/ sbin , / usr / sbin , / usr/bin 과 그와 류사한 등록부들에 있는 파일이름은 매우 긴 파일수명(몇 
달 혹은 그이상)을 더 가지 는것 처 럼 보인다. / home 등록부에 있는 파일들은 중간정 도의 
수명 즉 몇주일 혹은 그이상의 수명을 가지는것 같이 보인다. 八에•에 있는 파일들은 보통 
수명 이 짧다. Avar / spool / news 의 파일들은 며 칠 이상 남아 있게 되며 / var / spool / lpd 의 파일들 
은 그 수명이 몇분 혹은 그보다 더 적게 측정된다. 

여벌복사에서 수명은 매일매일의 여벌복사량이 단일한 여벌복사의 중간정도의 용량 
보다 더 작으면 아주 쓸모 있다. 매 일매 일의 여 벌복사는 완전여벌복사로 될수 있거 나 혹 
은 증가형 여벌 복사로 된 다. 

사용자는 구획의 크기가 하나의 여벌복사의 중간값에 완전히 일치시킬수 있는 정도 
로 충분히 작게 보존되도록 할수 있다. 임의의 경우에 구획은 매일매일의 델타(변경된 
모든 파일)가 하나의 여벌복사의 중간에 일치시킬수 있을 정도로 작아야 한다. 사용자의 
여벌복사방책은 그것의 결정에 의존한다. 

자료의 재 생성비 용은 가상적 으로 임의의 정 보에 대 한 여 벌복사비 용보다 훨씬 더 높 
다. 성 능을 보존하기 위하여 서 로 다른 구획 상에 서 서 로 다른 생 명 주기 를 가진 파일 들을 
보존하는것 이 아주 좋다. 새 소식구획 우에 서 짧은 수명 을 가진 파일들을 단편화할수 있는 
방법 은 대 단히 중요하다. 이 방법 은 /구획 이 나 / home 구획의 성 능에 영 향을 주지 않는다. 

4. 실 례 

4.1 . 초학자들을 위한 권고안 

우에 서 언급된것 처 럼 공통모형 은 /, / home , / var 구획 을 생 성 한다. 이 모형 을 설 치 하고 
유지 하는것 은 단순하며 서 로 다른 수명 으로부터 불리한 효과들을 충분히 구별 할수 있 다. 
또한 이 모형 은 여 벌 복사모형 과도 잘 일 치한다. USENET 새 소식 spool 을 여 벌 복사하는데 
는 근심거리가 거의 없으며 / var 의 일부 파일들만 여벌복사할 가치가 있다. 다른 말로 말 
하여 /는 이따금 변하며 요구에 따라 여벌복사할수 있으며 대다수의 현대적매체에 완전 
여 벌복사로 일 치 시 킬수 있을만큼 충분히 작다(설 치 된 프로그람의 크기 에 따라 
250-500 MB 를 예견한다.). / home 는 쓸모 있는 사용자자료를 포함하며 매 일 여 벌복사하여 
야 한다. 일부 설 치는 매 우 큰 / home 을 가지 며 증가형 여벌복사를 리용해 야 한다. 

일부 체 계 들은 / tap 를 개 별적디 스크에 배 치 하고 있으며 다른 체 계 들은 동일한 효과 
를 얻기 위 하여 / var / tmp 에 그것을 기 호련결로 련결한다(이 조작은 단일사용자방식 에서 
효과적이지만 이 방식에서는 八^요를 리 용할수 없다. 체계는 사용자가 八 ^ ar 를 생성 하거나 
Mir 를 수동적으로 올려태우기 할 때까지 혹은 RAM 디스크에 배치 할 때까지 이것을 가질 
수 없다는데 대 하여 강조한다.). 
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이 모형은 갱신뿐아니라 재설치에서도 아주 편리하다. 사용자의 배치구성파일(혹은 
/etc 전체)을 /home 등록부에 기 억시키고 /등록부를 제 거 하며 /home 상에 기 억된 등록부로부 
터 변경 된 배 치 구성 을 재 설정 하고 선행불러 내 기한다. 

5.실현방법 

변경된 ISA bus 386/40 을 홈용 LAN 을 위 한 소형 x-less 봉사기 로 돌린 경험을 소개 한 
다. 해 6 을 선택 하고 거 기에 16MB RAM 을 설치 하여 쉽게 엄 을수 있는 제 일 작은 디 스크 
인 (800MB) 값 눅은 EIDE 디스크와 e 比 lernet 카드를 추가한다. Linux 가 설치되 고 현시장치 
도 포함되여 있었기때문에 Herclules 도 추가하였다. 다음에 국부 NFS, SMB, HTTP, 
LPD/LPR 와 NNTP 봉사기 뿐만아니 라 우편 경 로조종기 와 POP3 봉사기 를 결 합하였 다. 보충적 
인 ISDN 카드에 의 하여 콤퓨터 는 TCP/IP 경 로조종기 로도 되 고 방화벽 으로도 되 였 다. 이 
기계상에서 대부분의 디스크공간은 Mir 등록부， /var/spool/mail, /var/spool/news 그리고 
/var/httpd/ 

html 로 되였다. 다음 "ar 를 개별디스크에 놓고 이것을 한개 등록부로 크게 만들었다. 이 
기계상에 더 이상 사용자들이 없기때문에 홈구획은 만들지 않고 NFS 를 거쳐 다른 워크스 
테 이 션 으로부터 /home 을 올려 태 우기 하였 다. 표와 몇 개 의 국부적 인 설 치 나 편의 프로그람 
없이 Linux 로써 250MB 구획으로 잘 진행 되였다. 기계가 16MB 의 RAM 을 가지고 있었지 만 
많은 봉사기 들을 운영할수 있었으며 16MB 이면 적 당하였고 32MB 이 면 충분하였다. 여 기서 
엄은 내용은 다음과 갈다. 


장 치 

올려태우기점 

크 기 

/dev/hdal 

/ dos_c 

25MB 

/dev/hda2 

一 (Swapspace) 

32MB 

/dev/hda3 

/ 

250MB 

/dev/hda4 

一 (Extended container) 

500MB 

/dev/hda5 

/ var 

500MB 

homeserver : /home /home 1.6GB 


홈봉사기에서 레프를 리용하는 망을 거쳐 이 기계와 접속된다. 이 기계상의 
모든것이 CD-ROM 으로부터 설치되였기때문에 /etc 로부터 일부 배치구성파일들과 
/root/source 로부터 주문화되고 국부적으로 설치된 *. Tgz 를 기억시킨다. 그리고 
/var/spool/mail 뿐아니 라 /var/httpd/html 도 기 억시 킨다. 이 파일들을 매 일밤 홈봉사 
기 의 /home/backmeup 등록부에 복사하는데 정 규홈봉사기 여벌복사가 그것 들을 선 택 
한다. 
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